This is something that has come out of a thread I have opened in
D.learn.
In the thread qznc has answered me:
Operator precedence of . is higher than unary minus.
That's right:
double foo(in double x) {
assert (x = 0);
return x;
}
void main() {
assert(-1.foo == -1);
}
Is
On Friday, 8 November 2013 at 12:49:38 UTC, bearophile wrote:
This is something that has come out of a thread I have opened
in D.learn.
In the thread qznc has answered me:
Operator precedence of . is higher than unary minus.
That's right:
double foo(in double x) {
assert (x = 0);
On Friday, 8 November 2013 at 12:53:24 UTC, Daniel Kozak wrote:
On Friday, 8 November 2013 at 12:49:38 UTC, bearophile wrote:
This is something that has come out of a thread I have opened
in D.learn.
In the thread qznc has answered me:
Operator precedence of . is higher than unary minus.
On Friday, 8 November 2013 at 12:49:38 UTC, bearophile wrote:
Is this a good design of the operator precedences? Is this
worth changing/fixing?
Bye,
bearophile
Yes it is expected and reasonable to me. Otherwise you'd need
brackets for every expression like this: `-aggregate.field`
Dicebot:
Yes it is expected and reasonable to me. Otherwise you'd need
brackets for every expression like this: `-aggregate.field`
For me it's weird... :-)
Thank you for the answers.
Bye,
bearophile
For me it's weird... :-)
import std.math;
assert (-3.abs == 0 - 3.abs);
assert ((-3).abs == (0 - 3).abs);
Makes sense..
On 11/08/13 14:59, bearophile wrote:
Dicebot:
Yes it is expected and reasonable to me. Otherwise you'd need brackets for
every expression like this: `-aggregate.field`
For me it's weird... :-)
The weirdness does not really come from the op precedence, but UFCS and
literals. Ie there's
On Friday, 8 November 2013 at 12:49:38 UTC, bearophile wrote:
This is something that has come out of a thread I have opened
in D.learn.
In the thread qznc has answered me:
Operator precedence of . is higher than unary minus.
That's right:
double foo(in double x) {
assert (x = 0);
