Re: Interesting user mistake

[Marco Leise via Digitalmars-d]

Am Fri, 4 Sep 2015 19:13:45 -0400
schrieb Andrei Alexandrescu :

> 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

Re: Interesting user mistake

[Marco Leise via Digitalmars-d]

Am Fri, 04 Sep 2015 13:38:26 +
schrieb "Jonathan M Davis" :

> 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

Re: Interesting user mistake

[Martin Nowak via Digitalmars-d]

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

Re: Interesting user mistake

[Sebastiaan Koppe via Digitalmars-d]

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.

Re: Interesting user mistake

[ponce via Digitalmars-d]

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?

Re: Interesting user mistake

[Mint via Digitalmars-d]

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.

Re: Interesting user mistake

[Steven Schveighoffer via Digitalmars-d]

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

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

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, --


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> has resulted in the C++98 parsers thinking that the >> on 
the end is a shift operator rather than the closing halves of the 
two templates, and C++11, Java, and C# have all had to _not_ use 
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

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

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

Re: Interesting user mistake

[immu via Digitalmars-d]

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.

Re: Interesting user mistake

[Mike James via Digitalmars-d]

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, --

Re: Interesting user mistake

[via Digitalmars-d]

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;

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

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

Re: Interesting user mistake

[Jonathan M Davis via Digitalmars-d]

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

Re: Interesting user mistake

[Steven Schveighoffer via Digitalmars-d]

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

Re: Interesting user mistake

[via Digitalmars-d]

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.

Re: Interesting user mistake

[skoppe via Digitalmars-d]

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?

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

On 09/03/2015 01:15 PM, "Luís Marques   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

Re: Interesting user mistake

[Observer via Digitalmars-d]

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, 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 C did not contain a unary + operator (K, 1/e, p. 37, 
Section 2.5).  It was added by the first ANSI C, "for symmetry 
with unary -" (K, 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

Re: Interesting user mistake

[Mint via Digitalmars-d]

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.

Re: Interesting user mistake

[Andrej Mitrovic via Digitalmars-d]

On 9/3/15, 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
> +=.

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?

Re: Interesting user mistake

[H. S. Teoh via Digitalmars-d]

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
>  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

Re: Interesting user mistake

[Andrej Mitrovic via Digitalmars-d]

On 9/4/15, H. S. Teoh via Digitalmars-d  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. :)

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

On 09/04/2015 04:41 PM, Andrej Mitrovic via Digitalmars-d wrote:

On 9/3/15, 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
+=.


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

Re: Interesting user mistake

[Steven Schveighoffer via Digitalmars-d]

On 9/4/15 9:38 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=  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

Re: Interesting user mistake

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Interesting user mistake

[via Digitalmars-d]

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. 
(). 
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();
}

Re: Interesting user mistake

[Meta via Digitalmars-d]

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.

Re: Interesting user mistake

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 03, 2015 at 06:44:54PM +, 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

Re: Interesting user mistake

[via Digitalmars-d]

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,
+
];

Re: Interesting user mistake

[Adam D. Ruppe via Digitalmars-d]

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!

Re: Interesting user mistake

[Mint via Digitalmars-d]

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.

Re: Interesting user mistake

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 03, 2015 at 06:31:57PM +, 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

Re: Interesting user mistake

[via Digitalmars-d]

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 
() 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.

Re: Interesting user mistake

[H. S. Teoh via Digitalmars-d]

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.

Re: Interesting user mistake

[via Digitalmars-d]

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?

Re: Interesting user mistake

[Steven Schveighoffer via Digitalmars-d]

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

Re: Interesting user mistake

[Enamex via Digitalmars-d]

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?

Re: Interesting user mistake

[via Digitalmars-d]

On Thursday, 3 September 2015 at 17:03:26 UTC, Luís Marques wrote:
I tried to search for that pattern 
() 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. 
(). All 
results are irrelevant, so I guess it's unlikely to break 
anything.

Re: Interesting user mistake

[jmh530 via Digitalmars-d]

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,
+
];


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.

Re: Interesting user mistake

[Brian Schott via Digitalmars-d]

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;

Re: Interesting user mistake

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 03, 2015 at 09:59:52PM +, 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