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