www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interesting user mistake

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

The gist of it is the user wrote =+ instead of +=. I wonder if we should 
disallow during tokenization the sequence "=", "+", whitespace. Surely 
it's not a formatting anyone would aim for, but instead a misspelling of +=.


Andrei
Sep 03 2015
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
 The gist of it is the user wrote =+ instead of +=. I wonder if 
 we should disallow during tokenization the sequence "=", "+", 
 whitespace. Surely it's not a formatting anyone would aim for, 
 but instead a misspelling of +=.
Seems reasonable. I tried to search for that pattern (<https://searchcode.com/?q=%3D%2B>) and it says 9 results for D, but clicking the D filter doesn't seem to do anything, so I'm not sure what the actual cases are.
Sep 03 2015
parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Thursday, 3 September 2015 at 17:03:26 UTC, Luís Marques wrote:
 I tried to search for that pattern 
 (<https://searchcode.com/?q=%3D%2B>) and it says 9 results for 
 D, but clicking the D filter doesn't seem to do anything, so 
 I'm not sure what the actual cases are.
Ah, there was a button way on the top to apply the filter. (<https://searchcode.com/?q=%3D%2B&loc=0&loc2=10000&lan=45>). All results are irrelevant, so I guess it's unlikely to break anything.
Sep 03 2015
parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Thursday, 3 September 2015 at 17:06:15 UTC, Luís Marques wrote:
 Ah, there was a button way on the top to apply the filter. 
 (<https://searchcode.com/?q=%3D%2B&loc=0&loc2=10000&lan=45>). 
 All results are irrelevant, so I guess it's unlikely to break 
 anything.
Urg, too trigger happy today. Bug?: https://searchcode.com/codesearch/view/15360834/ for (int i = 0; i < m_mainWindows.length; ++i) { tabCount =+ m_mainWindows[i].tabWidget().count(); }
Sep 03 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 03, 2015 at 12:46:29PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang
 
 The gist of it is the user wrote =+ instead of +=. I wonder if we
 should disallow during tokenization the sequence "=", "+", whitespace.
 Surely it's not a formatting anyone would aim for, but instead a
 misspelling of +=.
[...] Is there a way for the lexer to check for the specific character sequence '=', '+', whitespace and not others (e.g. '=', whitespace, '+')? IOW, "a =+ b" will be prohibited, but "a = + b" will be allowed. If so, I agree with this. On that note, though, the unary + operator is totally useless in D... maybe we should get rid of that instead? (Then "=+" will automatically be an error.) T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
Sep 03 2015
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:
 Is there a way for the lexer to check for the specific 
 character sequence '=', '+', whitespace and not others (e.g. 
 '=', whitespace, '+')?  IOW, "a =+ b" will be prohibited, but 
 "a = + b" will be allowed. If so, I agree with this.

 On that note, though, the unary + operator is totally useless 
 in D... maybe we should get rid of that instead?  (Then "=+" 
 will automatically be an error.)
What about the generalization? E.g., '=', '-', whitespace?
Sep 03 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/03/2015 01:15 PM, "Luís Marques  <luis luismarques.eu> wrote:
 On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:
 Is there a way for the lexer to check for the specific character
 sequence '=', '+', whitespace and not others (e.g. '=', whitespace,
 '+')?  IOW, "a =+ b" will be prohibited, but "a = + b" will be
 allowed. If so, I agree with this.

 On that note, though, the unary + operator is totally useless in D...
 maybe we should get rid of that instead?  (Then "=+" will
 automatically be an error.)
What about the generalization? E.g., '=', '-', whitespace?
Yah, '-' with the wrong spacing around it also makes sense. -- Andrei
Sep 04 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/3/15 1:08 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 03, 2015 at 12:46:29PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if we
 should disallow during tokenization the sequence "=", "+", whitespace.
 Surely it's not a formatting anyone would aim for, but instead a
 misspelling of +=.
[...] Is there a way for the lexer to check for the specific character sequence '=', '+', whitespace and not others (e.g. '=', whitespace, '+')? IOW, "a =+ b" will be prohibited, but "a = + b" will be allowed. If so, I agree with this. On that note, though, the unary + operator is totally useless in D... maybe we should get rid of that instead? (Then "=+" will automatically be an error.) T
What about all other operations that may be typos from op= where op is also a unary operator? e.g. =- FWIW, I think this is a good idea, even if it's just for =+. -Steve
Sep 03 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 3 September 2015 at 17:17:26 UTC, Steven 
Schveighoffer wrote:
 What about all other operations that may be typos from op= 
 where op is also a unary operator? e.g. =-
We'd have to special-case '*': a=*b;
Sep 03 2015
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 03, 2015 at 09:59:52PM +0000, Brian Schott via Digitalmars-d wrote:
 On Thursday, 3 September 2015 at 17:17:26 UTC, Steven Schveighoffer wrote:
What about all other operations that may be typos from op= where op
is also a unary operator? e.g. =-
We'd have to special-case '*': a=*b;
Not if we also look for whitespace after the '*'. But then applying the same rule to + would cause us to miss cases like a=+b while catching a =+ b. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
Sep 03 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/3/15 5:59 PM, Brian Schott wrote:
 On Thursday, 3 September 2015 at 17:17:26 UTC, Steven Schveighoffer wrote:
 What about all other operations that may be typos from op= where op is
 also a unary operator? e.g. =-
We'd have to special-case '*': a=*b;
You could say the same thing for =-: a=-b; seems reasonable for someone who doesn't like whitespace. I think Andrei's rule was the token sequence must have whitespace after the operator in order to be rejected. So the above would be fine. -Steve
Sep 04 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 4 September 2015 at 12:02:26 UTC, Steven Schveighoffer 
wrote:
 On 9/3/15 5:59 PM, Brian Schott wrote:
 On Thursday, 3 September 2015 at 17:17:26 UTC, Steven 
 Schveighoffer wrote:
 What about all other operations that may be typos from op= 
 where op is
 also a unary operator? e.g. =-
We'd have to special-case '*': a=*b;
You could say the same thing for =-: a=-b; seems reasonable for someone who doesn't like whitespace. I think Andrei's rule was the token sequence must have whitespace after the operator in order to be rejected. So the above would be fine.
Vector!double p; p.x=+ 0.27; p.y=-11.91; p.z=- 8.24;
Sep 04 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/4/15 9:38 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> wrote:
 On Friday, 4 September 2015 at 12:02:26 UTC, Steven Schveighoffer wrote:
 On 9/3/15 5:59 PM, Brian Schott wrote:
 On Thursday, 3 September 2015 at 17:17:26 UTC, Steven Schveighoffer
 wrote:
 What about all other operations that may be typos from op= where op is
 also a unary operator? e.g. =-
We'd have to special-case '*': a=*b;
You could say the same thing for =-: a=-b; seems reasonable for someone who doesn't like whitespace. I think Andrei's rule was the token sequence must have whitespace after the operator in order to be rejected. So the above would be fine.
Vector!double p; p.x=+ 0.27; p.y=-11.91; p.z=- 8.24;
p.x= + 0.27; p.y= -11.91; p.z= - 8.24; This really isn't a difficult thing to fix, nor do I likely see this being a common issue. -Steve
Sep 04 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/04/2015 08:02 AM, Steven Schveighoffer wrote:
 On 9/3/15 5:59 PM, Brian Schott wrote:
 On Thursday, 3 September 2015 at 17:17:26 UTC, Steven Schveighoffer
 wrote:
 What about all other operations that may be typos from op= where op is
 also a unary operator? e.g. =-
We'd have to special-case '*': a=*b;
You could say the same thing for =-: a=-b; seems reasonable for someone who doesn't like whitespace. I think Andrei's rule was the token sequence must have whitespace after the operator in order to be rejected. So the above would be fine.
Yah, that's what I was thinking. -- Andrei
Sep 04 2015
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:
 Is there a way for the lexer to check for the specific 
 character sequence '=', '+', whitespace and not others (e.g. 
 '=', whitespace, '+')?  IOW, "a =+ b" will be prohibited, but 
 "a = + b" will be allowed. If so, I agree with this.

 On that note, though, the unary + operator is totally useless 
 in D... maybe we should get rid of that instead?  (Then "=+" 
 will automatically be an error.)


 T
Worse than useless; it doesn't even behave as you would expect. import std.stdio; void main() { auto a = -1; writeln(+a); //Prints -1 writeln(-a); //Prints 1 } At least unary - does something.
Sep 03 2015
next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Thursday, 3 September 2015 at 18:31:59 UTC, Meta wrote:
 On that note, though, the unary + operator is totally useless 
 in D... maybe we should get rid of that instead?  (Then "=+" 
 will automatically be an error.)


 T
Worse than useless; it doesn't even behave as you would expect. import std.stdio; void main() { auto a = -1; writeln(+a); //Prints -1 writeln(-a); //Prints 1 } At least unary - does something.
I like to use the unary plus *in some cases* of tabular data, to reinforce the signess. Something like this: auto foo = [ +1234, -5678, -4242, +9999 ];
Sep 03 2015
parent "jmh530" <john.michael.hall gmail.com> writes:
On Thursday, 3 September 2015 at 18:37:53 UTC, Luís Marques wrote:
 I like to use the unary plus *in some cases* of tabular data, 
 to reinforce the signess. Something like this:

 auto foo = [
     +1234,
     -5678,
     -4242,
     +9999
 ];
I don't do it often, but I've seen lots of people do it too in other languages. Most notably, I see a lot of the older people in my office will start excel equations with + instead of =, then excel will add in a =+. I think something like Lotus-1-2-3 did things that way and they never changed.
Sep 03 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 03, 2015 at 06:31:57PM +0000, Meta via Digitalmars-d wrote:
 On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:
Is there a way for the lexer to check for the specific character
sequence '=', '+', whitespace and not others (e.g. '=', whitespace,
'+')?  IOW, "a =+ b" will be prohibited, but "a = + b" will be
allowed. If so, I agree with this.

On that note, though, the unary + operator is totally useless in D...
maybe we should get rid of that instead?  (Then "=+" will
automatically be an error.)


T
Worse than useless; it doesn't even behave as you would expect. import std.stdio; void main() { auto a = -1; writeln(+a); //Prints -1 writeln(-a); //Prints 1 } At least unary - does something.
Sure it behaves as expected: it's the opposite of unary -, which negates the sign, so unary + does not negate the sign. I.e., it's a no-op. Therefore, it's useless. :-) Now, in C, unary + actually does something -- it causes promotion of narrow ints to int. I'm not sure if it does that in D as well. But it's one of those obscure things that people will probably only discover when it shows up as a bug in their code. I'm in favor of killing it outright. T -- MSDOS = MicroSoft's Denial Of Service
Sep 03 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 3 September 2015 at 18:42:37 UTC, H. S. Teoh wrote:
 Now, in C, unary + actually does something -- it causes 
 promotion of narrow ints to int. I'm not sure if it does that 
 in D as well.
what is this, javascript? a|0 :P Seriously though, I never knew that. And I can't find where unary + is defined in D... I see the grammar line, but not explanation of what it actually does. Perhaps it is meant to be self-evident!
Sep 03 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Sep 03, 2015 at 06:44:54PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
 On Thursday, 3 September 2015 at 18:42:37 UTC, H. S. Teoh wrote:
Now, in C, unary + actually does something -- it causes promotion of
narrow ints to int. I'm not sure if it does that in D as well.
what is this, javascript? a|0 :P Seriously though, I never knew that.
I didn't either, until I googled it just now. :-D
 And I can't find where unary + is defined in D... I see the grammar
 line, but not explanation of what it actually does.
 
 Perhaps it is meant to be self-evident!
Hmm, apparently it does *not* do type promotion in D, at least according to this code: ubyte x = 1; pragma(msg, typeof(x)); // prints "ubyte" pragma(msg, typeof(+x)); // prints "ubyte" So sounds like it's a real no-op in D. T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Sep 03 2015
prev sibling next sibling parent "Mint" <mintie wute.com> writes:
On Thursday, 3 September 2015 at 18:31:59 UTC, Meta wrote:
 Worse than useless; it doesn't even behave as you would expect.

 import std.stdio;

 void main()
 {
 	auto a = -1;
 	writeln(+a); //Prints -1
         writeln(-a); //Prints  1
 }

 At least unary - does something.
I mean, if behaves exactly as I'd expect. +(-1) must equal -1, as -(-1) produces +1. Also, recall that you can overload the unary + operator, so it may behave differently for some aggregate types.
Sep 03 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 3 September 2015 at 18:31:59 UTC, Meta wrote:
 On Thursday, 3 September 2015 at 17:12:31 UTC, H. S. Teoh wrote:
 Is there a way for the lexer to check for the specific 
 character sequence '=', '+', whitespace and not others (e.g. 
 '=', whitespace, '+')?  IOW, "a =+ b" will be prohibited, but 
 "a = + b" will be allowed. If so, I agree with this.

 On that note, though, the unary + operator is totally useless 
 in D... maybe we should get rid of that instead?  (Then "=+" 
 will automatically be an error.)


 T
Worse than useless; it doesn't even behave as you would expect. import std.stdio; void main() { auto a = -1; writeln(+a); //Prints -1 writeln(-a); //Prints 1 } At least unary - does something.
I didn't realize that a unary + operator existed. I would have assumed that +a as an expression would be illegal. It doesn't even mean anything. - Jonathan M Davis
Sep 04 2015
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 04 Sep 2015 13:38:26 +0000
schrieb "Jonathan M Davis" <jmdavisProg gmx.com>:

 I didn't realize that a unary + operator existed. I would have 
 assumed that +a as an expression would be illegal. It doesn't 
 even mean anything.
 
 - Jonathan M Davis
Often (mostly with linear algebra) you have e.g. a sum of 4 products that differ only in some index and the sign. I use to put superfluous + signs there and put each product on a separate line just to make the similarities stick out more. Sure they do nothing, but I'd miss them when there is ++/--/- as prefix operators but no +. About the proposal I'm undecided. Rare mistake, stuffing more fuzzy logic into the compiler front-end where I don't know how maintainable this is on the long run and how much in fact they start to annoy as they target mistakes that newcomers make, but may actually be legit. For example assuming you learned the operator precedence rules, warnings about adding parenthesis where the code was already correct can be annoying. "=+ " goes in the same direction. We could end up with DMD and SDC implementing a different set of somewhat fuzzy, well meant restrictions on what is correct code, that most of the time avoid errors and sometimes annoy. A compiler front-end is complex and such language patches may actually make the code less readable by adding snippets of code all over the front-end code bases. I like the "did you mean ..." messages though as the last step of symbol resolution. They happen when the code already doesn't compile and as such don't alter what is valid code and they have good visibility. So my opinion is to collect such snippets in a proper linter like https://github.com/Hackerpilot/Dscanner instead of burdening the front-end with them and creating a de-facto new DMD specific spec different from other emerging D implementations. -- Marco
Sep 13 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/03/2015 01:08 PM, H. S. Teoh via Digitalmars-d wrote:
 On Thu, Sep 03, 2015 at 12:46:29PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if we
 should disallow during tokenization the sequence "=", "+", whitespace.
 Surely it's not a formatting anyone would aim for, but instead a
 misspelling of +=.
[...] Is there a way for the lexer to check for the specific character sequence '=', '+', whitespace and not others (e.g. '=', whitespace, '+')? IOW, "a =+ b" will be prohibited, but "a = + b" will be allowed. If so, I agree with this.
Yah, space is relevant there. That's why the check is easiest done during tokenization. -- Andrei
Sep 04 2015
parent reply "Mint" <mintie wute.com> writes:
On Friday, 4 September 2015 at 17:17:26 UTC, Andrei Alexandrescu 
wrote:
 On 09/03/2015 01:08 PM, H. S. Teoh via Digitalmars-d wrote:
 [...]

 Is there a way for the lexer to check for the specific 
 character
 sequence '=', '+', whitespace and not others (e.g. '=', 
 whitespace,
 '+')?  IOW, "a =+ b" will be prohibited, but "a = + b" will be 
 allowed.
 If so, I agree with this.
Yah, space is relevant there. That's why the check is easiest done during tokenization. -- Andrei
Given ` a =+ b `, I see no issue with the statement assuming 'b' is of some type T that overloads the unary + operator. ie. ` a = b.opUnary!"+" ` And while the expression could also be written as ` a = +b `, there's a number of situations where it's hard to control the formatting (ie. generated mixin code). That, and I can't think of any other C-like language where ` =+ ` would produce an error. A simple solution would be to just have unary + perform integer promotion, as it does in C.
Sep 04 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/04/2015 02:55 PM, Mint wrote:
 On Friday, 4 September 2015 at 17:17:26 UTC, Andrei Alexandrescu wrote:
 On 09/03/2015 01:08 PM, H. S. Teoh via Digitalmars-d wrote:
 [...]

 Is there a way for the lexer to check for the specific character
 sequence '=', '+', whitespace and not others (e.g. '=', whitespace,
 '+')?  IOW, "a =+ b" will be prohibited, but "a = + b" will be allowed.
 If so, I agree with this.
Yah, space is relevant there. That's why the check is easiest done during tokenization. -- Andrei
Given ` a =+ b `, I see no issue with the statement assuming 'b' is of some type T that overloads the unary + operator. ie. ` a = b.opUnary!"+" ` And while the expression could also be written as ` a = +b `, there's a number of situations where it's hard to control the formatting (ie. generated mixin code). That, and I can't think of any other C-like language where ` =+ ` would produce an error. A simple solution would be to just have unary + perform integer promotion, as it does in C.
I am now sorry I started this. -- Andrei
Sep 04 2015
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 4 September 2015 at 18:55:03 UTC, Mint wrote:
 On Friday, 4 September 2015 at 17:17:26 UTC, Andrei

 A simple solution would be to just have unary + perform integer 
 promotion, as it does in C.
Wait, what? Is this another secret difference from C integer promotion rules?
Sep 05 2015
parent "Mint" <mintie wute.com> writes:
On Saturday, 5 September 2015 at 10:45:35 UTC, ponce wrote:
 On Friday, 4 September 2015 at 18:55:03 UTC, Mint wrote:
 On Friday, 4 September 2015 at 17:17:26 UTC, Andrei

 A simple solution would be to just have unary + perform 
 integer promotion, as it does in C.
Wait, what? Is this another secret difference from C integer promotion rules?
To me knowledge, the unary '+' in D is essentially a no-op (much like it is in Java). Mimicking C promotion rules might help new programmers coming to D from C or C++ feel more familiar with the language. The caveat here would be that the unary '-' operator would need to also perform a similar promotion for consistency.
Sep 05 2015
prev sibling next sibling parent reply "Enamex" <enamex+d outlook.com> writes:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
 we should disallow during tokenization the sequence "=", "+", 
 whitespace. Surely it's not a formatting anyone would aim for, 
 but instead a misspelling of +=.


 Andrei
Wasn't the original design for these operators in whichever language started them actually the swapped form? In any case, I'd personally choose to warn against any operator sequence without separating whitespaces if the sequence isn't in fact one operator (like "=!" (non-warn: "= !") vs "!=", and "=&", and a lot others, given operator overloading). Looking again, it's mostly the fault of OpAssign operators, isn't it?
Sep 03 2015
parent "Observer" <spurious.address yahoo.com> writes:
On Thursday, 3 September 2015 at 17:15:25 UTC, Enamex wrote:
 On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
 Alexandrescu wrote:
 we should disallow during tokenization the sequence "=", "+", 
 whitespace. Surely it's not a formatting anyone would aim for, 
 but instead a misspelling of +=.
Wasn't the original design for these operators in whichever language started them actually the swapped form? In any case, I'd personally choose to warn against any operator sequence without separating whitespaces if the sequence isn't in fact one operator (like "=!" (non-warn: "= !") vs "!=", and "=&", and a lot others, given operator overloading).
The += operator originally appeared in C, as the =+ operator (K&R, 1/e, p212, "Anachronisms"). Not long afterward, the ambiguity of a=+b became apparent, along with the obvious need to change the language to resolve the problem. The issue was dealt with over several successive releases of the compiler: (1) =+ operator is available (original compiler) (2) =+ and += are both available (I'm not sure whether this step existed) (3) =+ and += are both available; =+ produces a deprecation warning (4) += is available; =+ now produces either a warning/error or just changes meaning, not sure which I don't recall now where I read about that sequence of steps, and a quick, incomplete scan of my library doesn't yield it up so I could be more precise. Nonetheless, that's how the transition happened. The Rationale for the original ANSI C (X3.159-1989) mentions that =op forms have been dropped, and that in a Quiet Change, "expressions of the form x=-3 change meaning with the loss of the old-style assignment operators". Which I suppose implies that the Standard itself doesn't require a warning message, though presumably high-quality compilers would be free to implement one. K&R C did not contain a unary + operator (K&R, 1/e, p. 37, Section 2.5). It was added by the first ANSI C, "for symmetry with unary -" (K&R, 2/e, p204, Section A7.4.4). "An integral operand undergoes integral promotion." In terms of compiler quality, we have a long history of compilers generating warning messages for legal but questionable constructions. The first one that comes quickly to mind is GCC complaining about "if(a=b)": warning: suggest parentheses around assignment used as truth value [-Wparentheses] The notion here is that a common mistake is handled by: (a) being warned about, when warnings are enabled (at least, by -Wall in GCC) (b) having an alternate construction suggested (e.g., "if((a=b))") (c) having a specific compiler flag to control generation of each such warning
Sep 04 2015
prev sibling next sibling parent reply "immu" <immutablestate hotmail.de> writes:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
 I wonder if we should disallow during tokenization the sequence 
 "=", "+", whitespace. Surely it's not a formatting anyone would 
 aim for, but instead a misspelling of +=.


 Andrei
Please don't. That would feel like a completely arbitrary exception in the grammar.
Sep 04 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/04/2015 08:47 AM, immu wrote:
 On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei Alexandrescu wrote:
 I wonder if we should disallow during tokenization the sequence "=",
 "+", whitespace. Surely it's not a formatting anyone would aim for,
 but instead a misspelling of +=.


 Andrei
Please don't. That would feel like a completely arbitrary exception in the grammar.
Not a good counterargument! -- Andrei
Sep 04 2015
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if 
 we should disallow during tokenization the sequence "=", "+", 
 whitespace. Surely it's not a formatting anyone would aim for, 
 but instead a misspelling of +=.
Well, in this particular case, wouldn't it make more sense to simply make + as a unary operator illegal? It doesn't even _do_ anything, and I, for one, didn't even know that such an operator existed before this thread. In general though, I think that warning based on whitespace is a slippery slope, especially when the language is designed such that whitespace doesn't matter unless it's required to make it so that a compound token is separate tokens. And this particular case isn't even generalizable, because there are other operators where they _would_ go in that order, and if you don't actually want to properly space out your operators with whitespace, then you'll end up with stuff like =-a and =*a which are perfectly legitimate. So, we're forced to either special case =+, or we're essentially going to require that you put a space after =, and while I think that everyone should, that's basically requiring folks to format their code in a particular way which isn't in line with D or its C/C++ ancestry and the expectations of the developers who use such languages. So, honestly, I'm more inclined to tell folks that maybe if they want their code to be clear and avoid mistakes like this, they should put whitespace around operators, but it's a free world, and they're free to format their code in a way that's harder to read and more likely to help them shoot themselves in the foot if they really want to. But regardless, I question that even allowing + as a unary operator even makes sense in the first place. I guess that some folks might use it to try and make the difference between a positive and a negative number more obvious? But I would have thought that it would make it _harder_ to distinguish them rather than easier. So, maybe we can just get rid of the unary + operator. But still, that would only help this particular case, and other operators which _do_ make sense as unary operators to the right of an assignment still have the potential of being mistyped to painful results if programmers don't actually put whitespace around = like most of us would. - Jonathan M Davis
Sep 04 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis 
wrote:
 On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
 Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if 
 we should disallow during tokenization the sequence "=", "+", 
 whitespace. Surely it's not a formatting anyone would aim for, 
 but instead a misspelling of +=.
[snip] Actually, I may have misunderstood the suggestion. I do _not_ think that we should require that someone who writes code like a=+b; should be forced to put whitespace in their code, as ugly as it arguably is that they don't (which is what I thought was being suggested). However, if they've written their code like a =+ b; then it would make sense to warn about it, since the odds of that being legitimate are nearly zero, and the same goes for any other unary operator. Someone might be weird and choose to put whitespace before the unary operator, but I don't think that that's very common, and if someone is doing that, they're not likely to then _not_ put a space before the unary operator. So, I don't think that we'd really be cramping anyone's style (be it ugly or otherwise) if we warned about =+ when there's whitespace on both sides of =+ but not between them. Now, I tend to think that anything should either be an error or not and that everything else should be left to a linter, since it's subjective, so I'm still not a big fan about having something like this be a warning, but I very much doubt that it'll really cause any problems if it is, since I have a hard time believing that anyone is even going to _want_ to write a =+ b; - Jonathan M Davis
Sep 04 2015
next sibling parent reply "Mike James" <foo bar.com> writes:
On Friday, 4 September 2015 at 14:05:09 UTC, Jonathan M Davis 
wrote:
 On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis 
 wrote:
 [...]
[snip] [...]
Isn't it called Maximal Munch... https://en.wikipedia.org/wiki/Maximal_munch Regards, -<mike>-
Sep 04 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 4 September 2015 at 14:14:43 UTC, Mike James wrote:
 On Friday, 4 September 2015 at 14:05:09 UTC, Jonathan M Davis 
 wrote:
 On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis 
 wrote:
 [...]
[snip] [...]
Isn't it called Maximal Munch... https://en.wikipedia.org/wiki/Maximal_munch Regards, -<mike>-
Yes. That's how most languages typically parse tokens, but some programming languages are more willing to force formatting on you than others, even if they use maximal munch. You _can_ choose to make certain uses of whitespace illegal while still using maximal munch, since all that maximal munch is doing is deciding how you're going to know whether a sequence of characters is one token or several when it's ambiguous. It's why vector<pair<int, int>> has resulted in the C++98 parsers thinking that the >> on the end is a shift operator rather than the closing halves of the maximal munch in that particular case to make it so that it's not treated as the shift-operator. It makes their grammars that much less context-free and is part of why D uses !() for template instantiations. In any case, I didn't use the term maximal munch, because that indicates how tokens are separated and says nothing about how you format your code (aside from the fact that you sometimes have to add whitespace to disambiguate if the grammar isn't clean enough), whereas this discussion really has to do with making formatting your code in a particular instance illegal (or at least that the compiler would warn about it, which is essentially equivalent to making it illegal, since no one should leave warnings in their code, and -w literally turns all warnings into errors anyway). There is no ambiguity as to whether =+ is the same as = + as far as the compiler is concerned, because there is no =+ token, and so maximal munch doesn't really even come into play here. - Jonathan M Davis
Sep 04 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/4/15 10:05 AM, Jonathan M Davis wrote:
 On Friday, 4 September 2015 at 13:55:03 UTC, Jonathan M Davis wrote:
 On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang


 The gist of it is the user wrote =+ instead of +=. I wonder if we
 should disallow during tokenization the sequence "=", "+",
 whitespace. Surely it's not a formatting anyone would aim for, but
 instead a misspelling of +=.
[snip] Actually, I may have misunderstood the suggestion. I do _not_ think that we should require that someone who writes code like a=+b; should be forced to put whitespace in their code, as ugly as it arguably is that they don't (which is what I thought was being suggested). However, if they've written their code like a =+ b; then it would make sense to warn about it, since the odds of that being legitimate are nearly zero, and the same goes for any other unary operator.
I think that is Andrei's original suggestion: the sequence "=", "+", whitespace should be rejected. He says nothing about "=","+" without the whitespace. -Steve
Sep 04 2015
parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Friday, 4 September 2015 at 15:13:08 UTC, Steven Schveighoffer 
wrote:
 I think that is Andrei's original suggestion:

 the sequence "=", "+", whitespace should be rejected.

 He says nothing about "=","+" without the whitespace.
Yup.
Sep 04 2015
prev sibling next sibling parent reply "skoppe" <mail skoppe.eu> writes:
On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if 
 we should disallow during tokenization the sequence "=", "+", 
 whitespace. Surely it's not a formatting anyone would aim for, 
 but instead a misspelling of +=.


 Andrei
Seems like a really, really small fish to catch. I wouldn't want to litter my codebase with those kind of rules. Besides, isn't stackoverflow about the answers and opinions, rather than about the questions?
Sep 04 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/04/2015 12:39 PM, skoppe wrote:
 On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang


 The gist of it is the user wrote =+ instead of +=. I wonder if we
 should disallow during tokenization the sequence "=", "+", whitespace.
 Surely it's not a formatting anyone would aim for, but instead a
 misspelling of +=.


 Andrei
Seems like a really, really small fish to catch. I wouldn't want to litter my codebase with those kind of rules.
I don't see what litter one would need you add to one's codebase?
 Besides, isn't stackoverflow about the answers and opinions, rather than
 about the questions?
That's not a criterion to judge any discussion that originates there. Andrei
Sep 04 2015
parent "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Friday, 4 September 2015 at 23:08:21 UTC, Andrei Alexandrescu 
wrote:
 On 09/04/2015 12:39 PM, skoppe wrote:
 On Thursday, 3 September 2015 at 16:46:30 UTC, Andrei 
 Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang


 The gist of it is the user wrote =+ instead of +=. I wonder 
 if we
 should disallow during tokenization the sequence "=", "+", 
 whitespace.
 Surely it's not a formatting anyone would aim for, but 
 instead a
 misspelling of +=.


 Andrei
Seems like a really, really small fish to catch. I wouldn't want to litter my codebase with those kind of rules.
I don't see what litter one would need you add to one's codebase?
I was speaking from the perspective of whoever maintains/wrote the tokenizer.
Sep 05 2015
prev sibling next sibling parent reply Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9/3/15, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if we should
 disallow during tokenization the sequence "=", "+", whitespace. Surely
 it's not a formatting anyone would aim for, but instead a misspelling of
 +=.
The gist of it is that it's interesting because it's such a rare occurrence. That's why we probably shouldn't even think about it. I've never seen such mistakes in OSS code before, and I've never seen it in production code either. It's so rare that we shouldn't spend any time thinking about it. Sure it's interesting, but why bother with this special case when there's bigger fish to fry?
Sep 04 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/04/2015 04:41 PM, Andrej Mitrovic via Digitalmars-d wrote:
 On 9/3/15, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if we should
 disallow during tokenization the sequence "=", "+", whitespace. Surely
 it's not a formatting anyone would aim for, but instead a misspelling of
 +=.
The gist of it is that it's interesting because it's such a rare occurrence. That's why we probably shouldn't even think about it. I've never seen such mistakes in OSS code before, and I've never seen it in production code either. It's so rare that we shouldn't spend any time thinking about it.
https://searchcode.com/codesearch/view/15360834/ was mentioned.
 Sure it's interesting, but why bother with this special case when
 there's bigger fish to fry?
Most likely. My question was whether to put it in bugzilla or not. Guess not. Andrei
Sep 04 2015
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 4 Sep 2015 19:13:45 -0400
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 Most likely. My question was whether to put it in bugzilla or not. Guess 
 not.
 
 
 Andrei
Put it here: https://github.com/Hackerpilot/Dscanner/issues ;) -- Marco
Sep 13 2015
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 04, 2015 at 10:41:05PM +0200, Andrej Mitrovic via Digitalmars-d
wrote:
 On 9/3/15, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang

 The gist of it is the user wrote =+ instead of +=. I wonder if we
 should disallow during tokenization the sequence "=", "+",
 whitespace. Surely it's not a formatting anyone would aim for, but
 instead a misspelling of +=.
The gist of it is that it's interesting because it's such a rare occurrence. That's why we probably shouldn't even think about it. I've never seen such mistakes in OSS code before, and I've never seen it in production code either. It's so rare that we shouldn't spend any time thinking about it. Sure it's interesting, but why bother with this special case when there's bigger fish to fry?
https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality :-) T -- "I'm not childish; I'm just in touch with the child within!" - RL
Sep 04 2015
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 9/4/15, H. S. Teoh via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality
The irony is that I now spend most of my time thinking about really pressing issues, I can finally see the forest for the trees. But I'm no longer an OSS dev so all of my effort goes into my company (which I love). I wish I had this kind of insight back in the day. :)
Sep 04 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 09/03/2015 06:46 PM, Andrei Alexandrescu wrote:
 http://stackoverflow.com/questions/32369114/leap-years-not-working-in-date-and-time-program-in-dlang
 
 
 The gist of it is the user wrote =+ instead of +=. I wonder if we should
 disallow during tokenization the sequence "=", "+", whitespace. Surely
 it's not a formatting anyone would aim for, but instead a misspelling of
 +=.
 
 
 Andrei
https://github.com/D-Programming-Language/dmd/pull/5072
Sep 13 2015