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 over
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 anythin
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 th
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 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?=
>>> " wrote:
One of C's design mistakes is t
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?=
" wrote:
One of C's design mistakes is to make assignments expressions and not
statements.
I think it is more a
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?=
> " 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
>
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?=
" 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 expressi
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 05/26/2015 06:35 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" 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 unnecessary.
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. -- A
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 o
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 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 += ba
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
ke
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 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 i
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
"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.
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 evalua
"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 overl
On 05/24/2015 09:30 PM, kinke wrote:
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 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. :-
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 m
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 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 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
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 ke
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?
in
"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].
C
On 05/25/2015 07:21 PM, Johannes Pfau wrote:
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu :
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
On 5/25/15 10:21 AM, Johannes Pfau wrote:
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu :
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 res
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu :
> 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
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 is
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 cas
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 beggi
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
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 somebod
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 5/24/15 3:36 PM, Iain Buclaw via Digitalmars-d wrote:
On 25 May 2015 00:20, "Andrei Alexandrescu via Digitalmars-d"
mailto: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.or
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/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 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
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 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 ab
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 t
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 it'
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:
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @propert
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:
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf("array()\n"); return _array;
}
int
On 05/24/2015 09:48 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
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 e
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 expressi
On Sunday, 24 May 2015 at 19:30:54 UTC, kinke wrote:
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;
55 matches
Mail list logo