On Tuesday, 26 May 2015 at 22:54:55 UTC, Timon Gehr wrote:
On 05/26/2015 07:48 PM, deadalnix wrote:
On Tuesday, 26 May 2015 at 12:51:20 UTC, Timon Gehr wrote:
I guess overloaded operators could be made to cache the old
value. (As
they do in CTFE, apparently. :o))
However, this seems like
On 05/26/2015 06:35 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
One of C's design mistakes is to make assignments expressions and not
statements.
I think it is more about returning void vs. returning the lvalue. The
expression/statement distinction is
On 05/26/2015 02:55 AM, deadalnix wrote:
On Tuesday, 26 May 2015 at 00:07:33 UTC, Timon Gehr wrote:
I'm fine with RTL for assignment expressions, and LTR everywhere else.
Daniel, if you could work this out at front end level so it goes the
same way for all backends, that would be fantastic. --
On 05/26/2015 02:51 PM, Timon Gehr wrote:
int a=0,b=0;
(b++,a)=b; // ltr gives a==1, rtl gives a==0, caching irrelevant
This should have said that caching _on the lhs_ is irrelevant.
On Tuesday, 26 May 2015 at 12:54:27 UTC, Timon Gehr wrote:
On 05/26/2015 06:35 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
One of C's design mistakes is to make assignments expressions
and not
statements.
I think it is more about returning void vs.
On Tuesday, 26 May 2015 at 12:51:20 UTC, Timon Gehr wrote:
I guess overloaded operators could be made to cache the old
value. (As they do in CTFE, apparently. :o))
However, this seems like overkill. Any other ideas?
They can but it wouldn't fix anything. The rvalue is already
evaluated by
On 05/26/2015 06:13 PM, Artur Skawina via Digitalmars-d wrote:
On 05/26/15 14:54, Timon Gehr via Digitalmars-d wrote:
On 05/26/2015 06:35 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
One of C's design mistakes is to make assignments expressions and not
On 05/26/15 14:54, Timon Gehr via Digitalmars-d wrote:
On 05/26/2015 06:35 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
One of C's design mistakes is to make assignments expressions and not
statements.
I think it is more about returning void vs.
On 05/26/2015 07:48 PM, deadalnix wrote:
On Tuesday, 26 May 2015 at 12:51:20 UTC, Timon Gehr wrote:
I guess overloaded operators could be made to cache the old value. (As
they do in CTFE, apparently. :o))
However, this seems like overkill. Any other ideas?
They can but it wouldn't fix
On 05/26/15 18:16, Timon Gehr via Digitalmars-d wrote:
On 05/26/2015 06:13 PM, Artur Skawina via Digitalmars-d wrote:
On 05/26/15 14:54, Timon Gehr via Digitalmars-d wrote:
On 05/26/2015 06:35 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
One of C's
On Tue, 26 May 2015 18:16:57 +0200, Timon Gehr wrote:
Sure, but there is no incentive to do this. a[i=j+1]=3; makes the code
shorter.
and harder to read. it is considered bad practice anyway, and will hardly
pass any serious code review.
signature.asc
Description: PGP signature
On 25 May 2015 01:10, Timon Gehr via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 05/25/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
This comes up once in a while. We should stick with left to right
through and through. It's a simple matter of getting somebody on the
On Monday, 25 May 2015 at 07:33:49 UTC, ketmar wrote:
On Sun, 24 May 2015 19:30:52 +, kinke wrote:
So for the 2nd assignment's left-hand-side, the index is
evaluated
before evaluating the container! Please don't tell me that's
by design.
:
it is. at least this is what i was told when i
On Sun, 24 May 2015 19:30:52 +, kinke wrote:
So for the 2nd assignment's left-hand-side, the index is evaluated
before evaluating the container! Please don't tell me that's by design.
:
it is. at least this is what i was told when i faced the similar issue.
WONTIFX, STFU.
signature.asc
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote:
it is, a slight change to the code could change the order. So,
the kind of stuff that you're complaining about not being able
to do really shouldn't be done regardless of how well-defined
the order of evaluation is. It's just
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote:
It might be completely well-defined and consistent, but it may
not be what you expect, and even if it is, a slight change to
the code could change the order.
If the behavior isn't what I expect (and I don't think that's
often
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and makes
changes to foo before returning to assign the updated results.
We're not addressing that. += is not supposed to do concurrency magic.
-- Andrei
On 5/25/15 1:00 AM, Jonathan M Davis wrote:
foo(++i, ++i);
More complete example:
table[++i] = objTable[++i].funcTable[++i](++i, ++i);
should be well defined and evaluate left to right.
Andrei
On Monday, 25 May 2015 at 12:38:29 UTC, kinke wrote:
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote:
It might be completely well-defined and consistent, but it may
not be what you expect, and even if it is, a slight change to
the code could change the order.
If the behavior
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and
makes changes to foo before returning to assign the updated results.
On Monday, 25 May 2015 at 17:21:05 UTC, Johannes Pfau wrote:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
So what about my previous example?
Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com...
which one is correct?
GDC. -- Andrei
I don't think it matters too much if we pick strict LTR, or keep dmd's
existing exception for assign expressions. IIRC Walter is in favour of
keeping the exception[1].
On 25 May 2015 21:00, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com.
..
which one is correct?
GDC. -- Andrei
I don't think it matters too much if we pick strict LTR, or keep dmd's
existing
On 25 May 2015 at 21:02, kinke via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 25 May 2015 at 17:21:05 UTC, Johannes Pfau wrote:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote:
So what about my previous example?
int b = 0;
((++b *= 5) *= 2) += ++b * (b -= 6);
DMD 2.067.1: 60, latest LDC: 65, GDC: ?
If the litmus test is What does GDC do?, then LDC is doing it the
correct way. :-)
Even
On 5/25/15 10:21 AM, Johannes Pfau wrote:
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and
makes changes to foo before
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote:
If the litmus test is What does GDC do?, then LDC is doing
it the correct way. :-)
Perfect. :)
On Monday, 25 May 2015 at 19:17:48 UTC, Timon Gehr wrote:
Even if it isn't. ;)
It is - on its merge-2.067 branch. ;)
On 25 May 2015 21:35, Timon Gehr via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 05/25/2015 09:28 PM, kinke wrote:
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote:
If the litmus test is What does GDC do?, then LDC is doing it the
correct way. :-)
Perfect. :)
On
Timon Gehr wrote in message news:mjvtqm$17d8$1...@digitalmars.com...
A related issue is that the rewrites documented at
http://dlang.org/operatoroverloading.html don't all preserve the order of
subexpressions. However, ideally, the order of evaluation would be
preserved.
As operator
On 05/25/2015 09:28 PM, kinke wrote:
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote:
If the litmus test is What does GDC do?, then LDC is doing it the
correct way. :-)
Perfect. :)
On Monday, 25 May 2015 at 19:17:48 UTC, Timon Gehr wrote:
Even if it isn't. ;)
It is - on its
Timon Gehr wrote in message news:mjvvq2$19hd$1...@digitalmars.com...
As operator overloading is defined in terms of lowering to function
calls, I think it's reasonable to decide the order of evaluation after
the lowering. This will still be consistent across compilers and
platforms.
But
On 05/25/2015 07:21 PM, Johannes Pfau wrote:
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and
makes changes to foo before
On 05/24/2015 09:30 PM, kinke wrote:
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array; }
int start() @property { printf(start()\n); return 0; }
int end() @property { printf(end()\n); return 1; }
void main()
{
On 05/25/2015 10:02 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:mjvtqm$17d8$1...@digitalmars.com...
A related issue is that the rewrites documented at
http://dlang.org/operatoroverloading.html don't all preserve the order
of subexpressions. However, ideally, the order of
On 5/25/15 11:58 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mjvlv5$vch$1...@digitalmars.com...
which one is correct?
GDC. -- Andrei
I don't think it matters too much if we pick strict LTR, or keep dmd's
existing exception for assign expressions. IIRC Walter is in
On 05/26/2015 01:45 AM, Andrei Alexandrescu wrote:
On 5/25/15 11:58 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mjvlv5$vch$1...@digitalmars.com...
which one is correct?
GDC. -- Andrei
I don't think it matters too much if we pick strict LTR, or keep dmd's
existing
On 05/25/2015 10:30 PM, Daniel Murphy wrote:
Timon Gehr wrote in message news:mjvvq2$19hd$1...@digitalmars.com...
As operator overloading is defined in terms of lowering to function
calls, I think it's reasonable to decide the order of evaluation after
the lowering. This will still be
On Monday, 25 May 2015 at 23:44:57 UTC, Andrei Alexandrescu wrote:
On 5/25/15 11:58 AM, Daniel Murphy wrote:
Andrei Alexandrescu wrote in message
news:mjvlv5$vch$1...@digitalmars.com...
which one is correct?
GDC. -- Andrei
I don't think it matters too much if we pick strict LTR, or
keep
On Monday, 25 May 2015 at 17:25:57 UTC, Andrei Alexandrescu wrote:
It's not += doing the magic, it's bar(). And it's not limited
to
concurrency, it happens with every side effect:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a +=
On Tuesday, 26 May 2015 at 00:07:33 UTC, Timon Gehr wrote:
I'm fine with RTL for assignment expressions, and LTR
everywhere else.
Daniel, if you could work this out at front end level so it
goes the
same way for all backends, that would be fantastic. -- Andrei
Why? Strictly left-to-right is
On Monday, 25 May 2015 at 15:35:02 UTC, Jonathan M Davis wrote:
would hope good code would avoid. But defining the order of
evaluation as left-to-right, doesn't make those problems go
away. At best, it makes them consistent, and that may be worth
it, but it's not a silver bullet. And it takes
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array; }
int start() @property { printf(start()\n); return 0; }
int end() @property { printf(end()\n); return 1; }
void main()
{
array[start..end] = 666;
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array; }
int start() @property { printf(start()\n); return 0; }
int end() @property { printf(end()\n); return 1;
On Sunday, 24 May 2015 at 19:48:05 UTC, Jonathan M Davis wrote:
The original code is clearly wrong. And forcing the order of
evaluation so that it's one way or the other just changes under
which cases you end up with bugs. Mutating in an expression
while using it multiple times in that
On 24 May 2015 23:30, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
The gcc backend obviously supports ordered operations, because some
operations are ordered today.
Iain has talked in the past about how
On 5/24/15 1:29 PM, Timon Gehr wrote:
BTW, the documentation contradicts itself on evaluation order:
http://dlang.org/expression.html
This comes up once in a while. We should stick with left to right
through and through. It's a simple matter of getting somebody on the
compiler team to find
On 05/25/2015 12:15 AM, Andrei Alexandrescu wrote:
On 5/24/15 1:29 PM, Timon Gehr wrote:
BTW, the documentation contradicts itself on evaluation order:
http://dlang.org/expression.html
This comes up once in a while. We should stick with left to right
through and through. It's a simple matter
On 05/25/2015 01:49 AM, Andrei Alexandrescu wrote:
I think LTR is the most sensible in all cases. -- Andrei
It is also what Java and C# do.
On 05/24/2015 10:35 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 20:30:00 UTC, Timon Gehr wrote:
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array()
On 25 May 2015 00:20, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/24/15 1:29 PM, Timon Gehr wrote:
BTW, the documentation contradicts itself on evaluation order:
http://dlang.org/expression.html
This comes up once in a while. We should stick with left to
On 05/25/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
This comes up once in a while. We should stick with left to right
through and through. It's a simple matter of getting somebody on the
compiler team to find the time for it. -- Andrei
I find it is not as clear cut as that. In
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array; }
int start() @property { printf(start()\n); return 0; }
int
On Sunday, 24 May 2015 at 20:30:00 UTC, Timon Gehr wrote:
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array;
}
On 05/24/2015 11:26 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
The gcc backend obviously supports ordered operations, because some
operations are ordered today.
Iain has talked in the past about how they're forced to work around the
backend to force
On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
The gcc backend obviously supports ordered operations, because
some operations are ordered today.
Iain has talked in the past about how they're forced to work
around the backend to force the order of operations for those
cases, and
On 5/24/15 3:36 PM, Iain Buclaw via Digitalmars-d wrote:
On 25 May 2015 00:20, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On 5/24/15 1:29 PM, Timon Gehr wrote:
BTW, the documentation contradicts itself on evaluation order:
56 matches
Mail list logo
