[Issue 6620] argument evaluation order inversed for extern(C)

https://issues.dlang.org/show_bug.cgi?id=6620 Nicholas Wilson changed: What|Removed |Added Status|REOPENED|RESOLVED CC|

[Issue 5749] (D1 only) argument evaluation order of chained function from right

https://issues.dlang.org/show_bug.cgi?id=5749 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: Slice expressions - exact evaluation order, dollar

On 12.07.2016 23:56, Iain Buclaw via Digitalmars-d wrote: > >What is the justification why the base should be evaluated as an lvalue? > Because changes made to a temporary get lost as they never bind back to the original reference. ... Which I'd expect. It is just like: int x = 0; assert(3

Re: Slice expressions - exact evaluation order, dollar

On Friday, 17 June 2016 at 19:59:09 UTC, kinke wrote: // LDC issue #1433 void main() { auto r = getBase()[getLowerBound($) .. getUpperBound($)]; assert(r == [ 2, 3 ]); } Firstly, it fails with DMD 2.071 because $ in the upper bound expression is 0, i.e., it doesn't reflect the updated

Re: Slice expressions - exact evaluation order, dollar

On Wednesday, 13 July 2016 at 21:06:28 UTC, kinke wrote: On Monday, 27 June 2016 at 02:38:22 UTC, Timon Gehr wrote: The point is that the slice expression itself does or does not see the updates based on whether I wrap base in a lambda or not. I don't really see a necessity for the lambda to

Re: Slice expressions - exact evaluation order, dollar

On Monday, 27 June 2016 at 02:38:22 UTC, Timon Gehr wrote: As far as I understand, for the first expression, code gen will generate a reference to a temporary copy of base, and for the second expression, it will generate a reference to base directly. If lwr() or upr() then update the ptr

Re: Evaluation order of "+="

On 13 July 2016 at 07:20, Timon Gehr via Digitalmars-d wrote: > On 12.07.2016 19:20, Andrei Alexandrescu wrote: >> >> On 7/12/16 5:15 AM, Johan Engelen wrote: >>> >>> On Tuesday, 12 July 2016 at 07:57:37 UTC, Johan Engelen wrote: On Tuesday, 12 July 2016 at

Re: Evaluation order of "+="

On 12.07.2016 19:20, Andrei Alexandrescu wrote: On 7/12/16 5:15 AM, Johan Engelen wrote: On Tuesday, 12 July 2016 at 07:57:37 UTC, Johan Engelen wrote: On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on

Re: Slice expressions - exact evaluation order, dollar

On 27 June 2016 at 04:38, Timon Gehr via Digitalmars-d wrote: > On 26.06.2016 20:08, Iain Buclaw via Digitalmars-d wrote: >> >> On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d >> wrote: >>> >>> On 26.06.2016 10:08, Iain Buclaw via

Re: Evaluation order of "+="

On 12 July 2016 at 01:04, Johan Engelen via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > LDC recently changed the evaluation order of "+=" (I think unintentionally, > some other eval order problems were fixed). Now, it is different from DMD. > I am going to argue

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 18:44:44 UTC, deadalnix wrote: On Tuesday, 12 July 2016 at 16:17:18 UTC, kink wrote: On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on that one. Great, so after that very

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 16:17:18 UTC, kink wrote: On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on that one. Great, so after that very lengthy discussion, why did nobody add a frigging test?! Argh.

Re: Evaluation order of "+="

On 7/12/16 5:15 AM, Johan Engelen wrote: On Tuesday, 12 July 2016 at 07:57:37 UTC, Johan Engelen wrote: On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on that one. The semantic is such as : int

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on that one. Great, so after that very lengthy discussion, why did nobody add a frigging test?! Argh.

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 07:57:37 UTC, Johan Engelen wrote: On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on that one. The semantic is such as : int plusEqual(ref int a, int b) { a = a + b; return

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 02:27:04 UTC, deadalnix wrote: There was a very lenghty discussion about this in the past. DMD is correct on that one. The semantic is such as : int plusEqual(ref int a, int b) { a = a + b; return a; } Thanks. Could this be added to the spec please?

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 05:46:58 UTC, Patrick Schluter wrote: What happens here in LDC is probably that the call is inlined and therefore losing the sequence point. That is one of the dangers of aggressive inlining. Going off-topic but briefly: all inlining in LDC happens by LLVM. With

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 05:46:58 UTC, Patrick Schluter wrote: On Tuesday, 12 July 2016 at 00:16:58 UTC, deadalnix wrote: On Monday, 11 July 2016 at 23:31:40 UTC, Danika wrote: On Monday, 11 July 2016 at 23:04:00 UTC, Johan Engelen wrote: LDC recently changed the evaluation order of "+

Re: Evaluation order of "+="

On Tuesday, 12 July 2016 at 00:16:58 UTC, deadalnix wrote: On Monday, 11 July 2016 at 23:31:40 UTC, Danika wrote: On Monday, 11 July 2016 at 23:04:00 UTC, Johan Engelen wrote: LDC recently changed the evaluation order of "+=" (I think unintentionally, some other eval order problems

Re: Evaluation order of "+="

On Monday, 11 July 2016 at 23:04:00 UTC, Johan Engelen wrote: LDC recently changed the evaluation order of "+=" (I think unintentionally, some other eval order problems were fixed). Now, it is different from DMD. I am going to argue that I think DMD's order is more useful in t

Re: Evaluation order of "+="

On Monday, 11 July 2016 at 23:31:40 UTC, Danika wrote: On Monday, 11 July 2016 at 23:04:00 UTC, Johan Engelen wrote: LDC recently changed the evaluation order of "+=" (I think unintentionally, some other eval order problems were fixed). Now, it is different from DMD. I am going to ar

Re: Evaluation order of "+="

On Monday, 11 July 2016 at 23:04:00 UTC, Johan Engelen wrote: LDC recently changed the evaluation order of "+=" (I think unintentionally, some other eval order problems were fixed). Now, it is different from DMD. I am going to argue that I think DMD's order is more useful in t

Evaluation order of "+="

LDC recently changed the evaluation order of "+=" (I think unintentionally, some other eval order problems were fixed). Now, it is different from DMD. I am going to argue that I think DMD's order is more useful in the context of fibers, and would like your opinion. Consider this cod

Re: Slice expressions - exact evaluation order, dollar

On 26.06.2016 20:08, Iain Buclaw via Digitalmars-d wrote: On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d wrote: On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote: Old codegen: _base = *(getBase()); _lwr = getLowerBound(_base.length); _upr =

Re: Slice expressions - exact evaluation order, dollar

On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d wrote: > On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote: >> >> Old codegen: >> >> _base = *(getBase()); >> _lwr = getLowerBound(_base.length); >> _upr = getUpperBound(_base.length); >> r = {.length=(_upr

Re: Slice expressions - exact evaluation order, dollar

On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote: > Evaluation order should be strictly left-to-right. DMD and GDC get it wrong > here. > It is evaluated left-to-right. getBase() -> getLowerBound() -> getUpperBound(). Ah, I see what you mea

Re: Slice expressions - exact evaluation order, dollar

On Sunday, 26 June 2016 at 08:08:58 UTC, Iain Buclaw wrote: Now when creating temporaries of references, the reference is stabilized instead. New codegen: *(_ptr = getBase()); _lwr = getLowerBound(_ptr.length); _upr = getUpperBound(_ptr.length); r = {.length=(_upr - _lwr), .ptr=_ptr.ptr +

Re: Slice expressions - exact evaluation order, dollar

>> evaluating the bounds expressions? > >> This has been triggered by > >> https://github.com/ldc-developers/ldc/issues/1433 as LDC loads the > >> pointer before evaluating the bounds. > > > > > > Evaluation order should be strictly left-to-right. DMD

Re: Slice expressions - exact evaluation order, dollar

s/ldc/issues/1433 as LDC loads the >> pointer before evaluating the bounds. > > > Evaluation order should be strictly left-to-right. DMD and GDC get it wrong > here. > It is evaluated left-to-right. getBase() -> getLowerBound() -> getUpperBound().

Re: Slice expressions - exact evaluation order, dollar

before or after evaluating the bounds expressions? This has been triggered by https://github.com/ldc-developers/ldc/issues/1433 as LDC loads the pointer before evaluating the bounds. Evaluation order should be strictly left-to-right. DMD and GDC get it wrong here.

Re: Slice expressions - exact evaluation order, dollar

Ping. Let's clearly define these hairy evaluation order details and add corresponding tests; that'd be another advantage over C++.

Slice expressions - exact evaluation order, dollar

The following snippet is interesting: <<< __gshared int step = 0; __gshared int[] globalArray; ref int[] getBase() { assert(step == 0); ++step; return globalArray; } int getLowerBound(size_t dollar) { assert(step == 1); ++step; assert(dollar == 0); globalArray = [

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

)); // with l-t-r and lowering: 8 t=(t=t*T(2))+(t=t+T(2)); // either 8 or 12, depending on whether evaluation order is preserved during lowering. r~=s.a,r~=t.a; return r; } I guess overloaded operators could be made to cache the old value. (As they do in CTFE, apparently. :o

Re: Evaluation order of index expressions

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.

Re: Evaluation order of index expressions

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.

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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.

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

case for left-to-right order), then the language should force me to express the intention differently. If it's not well-defined, I may not be aware of such issues until I use a different compiler. Allowing implementation-dependent evaluation order is just begging for additional bugs

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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.

Re: Evaluation order of index expressions

? int b = 0; ((++b *= 5) *= 2) += ++b * (b -= 6); DMD 2.067.1: 60, latest LDC: 65, GDC: ? This divergence probably doesn't have anything to do with the evaluation order, which seems to be identical (LTR), but rather how the lhs expression is treated (a double-nature as nested lvalue to be assigned

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

. But almost entirely arbitrary. Yes. I don't think this is particularly important, as depending on evaluation order is highly discouraged. Preserving the original order would require added complexity that I don't think is warranted. The compiler would just need to introduce some temporary

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

it is fine to fix the spec and let the compiler catch up later (with a warning in the spec). I'm not saying this is urgent, just that it is obvious how it ought to be. as depending on evaluation order is highly discouraged. ... Doesn't mean it won't happen. Having different evaluation order

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

over correctness, an issue the C follow-up language Go partially recognized by turning ++ and -- into statements. I agree with you that if an expression depends on evaluation order it is most likely either buggy or prone to become buggy when the program is modified later on. So

Evaluation order of index expressions

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;

Re: Evaluation order of index expressions

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;

Re: Evaluation order of index expressions

on the original code smell. I think the evaluation order should be well-defined by the language though, following the intuitive left-to-right order for cases like this. Left-hand-side before right-hand-side in assign statements, container before its index/index range, for the latter start before end

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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.

Re: Evaluation order of index expressions

this is not C. BTW, the documentation contradicts itself on evaluation order: http://dlang.org/expression.html There have been discussions on defining the order of evaluation from left-to-right such that it may happen, but there have been issues raised with it as well (particularly from an optimization

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

the container! Please don't tell me that's by design. : [origin: https://github.com/D-Programming-Language/phobos/pull/3311] Why would you expect the order to even be defined? Because this is not C. BTW, the documentation contradicts itself on evaluation order: http://dlang.org/expression.html

Re: Evaluation order of index expressions

itself on evaluation order: http://dlang.org/expression.html There have been discussions on defining the order of evaluation from left-to-right such that it may happen, but there have been issues raised with it as well (particularly from an optimization standpoint, though IIRC, it causes some

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: Evaluation order of index expressions

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

Re: [GDC] Evaluation order: Please update the dmd backend

Now I'm working to fix issue 6620 https://issues.dlang.org/show_bug.cgi?id=6620 https://github.com/D-Programming-Language/dmd/pull/4035 Kenji Hara 2014-04-01 20:49 GMT+09:00 Johannes Pfau nos...@example.com: I started fixing GDC bug #8 (*) which is basically that array op evaluation order

[Issue 6620] argument evaluation order inversed for extern(C)

https://issues.dlang.org/show_bug.cgi?id=6620 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code

[Issue 6620] argument evaluation order inversed for extern(C)

https://issues.dlang.org/show_bug.cgi?id=6620 --- Comment #4 from Kenji Hara k.hara...@gmail.com --- (In reply to Kenji Hara from comment #3) https://github.com/D-Programming-Language/dmd/pull/4035 A small supplemental documentation fix:

Re: [GDC] Evaluation order: Please update the dmd backend

Am Wed, 02 Apr 2014 00:04:42 +0200 schrieb Timon Gehr timon.g...@gmx.ch: On 04/01/2014 08:40 PM, Sarath Kodali wrote: ... The evaluation order of assign operators should not be LTR as they have right associativity. In a = b = c, c has to be evaluated first, then b and then a. Similarly

Re: [GDC] Evaluation order: Please update the dmd backend

Am Wed, 2 Apr 2014 00:54:40 +1100 schrieb Daniel Murphy yebbliesnos...@gmail.com: Iain Buclaw ibuc...@gdcproject.org wrote in message news:mailman.13.1396357117.19942.digitalmar...@puremagic.com... So you can write the patches then? :o) Sure, as long as you're not in a hurry.

Re: [GDC] Evaluation order: Please update the dmd backend

On Tuesday, 1 April 2014 at 22:04:43 UTC, Timon Gehr wrote: On 04/01/2014 08:40 PM, Sarath Kodali wrote: ... The evaluation order of assign operators should not be LTR as they have right associativity. In a = b = c, c has to be evaluated first, then b and then a. Similarly, in a = b + c, b+c

Re: [GDC] Evaluation order: Please update the dmd backend

On 2 Apr 2014 09:52, Sarath Kodali sar...@dummy.com wrote: On Tuesday, 1 April 2014 at 22:04:43 UTC, Timon Gehr wrote: On 04/01/2014 08:40 PM, Sarath Kodali wrote: ... The evaluation order of assign operators should not be LTR as they have right associativity. In a = b = c, c has

Re: [GDC] Evaluation order: Please update the dmd backend

Am Wed, 02 Apr 2014 07:47:23 + schrieb Sarath Kodali sar...@dummy.com: On Tuesday, 1 April 2014 at 22:04:43 UTC, Timon Gehr wrote: On 04/01/2014 08:40 PM, Sarath Kodali wrote: ... The evaluation order of assign operators should not be LTR as they have right associativity

Re: [GDC] Evaluation order: Please update the dmd backend

Am Wed, 2 Apr 2014 10:48:33 +0200 schrieb Johannes Pfau nos...@example.com: http://dpaste.dzfl.pl/19c118b7d368 BTW: LDC and even very old versions of GDC already evaluate that LTR, you can switch the compiler to LDC to see that: http://dpaste.dzfl.pl/cec5cc3b7dd7

Re: [GDC] Evaluation order: Please update the dmd backend

On Wednesday, 2 April 2014 at 08:02:36 UTC, Iain Buclaw wrote: On 2 Apr 2014 09:52, Sarath Kodali sar...@dummy.com wrote: On Tuesday, 1 April 2014 at 22:04:43 UTC, Timon Gehr wrote: On 04/01/2014 08:40 PM, Sarath Kodali wrote: ... The evaluation order of assign operators should not be LTR

Re: [GDC] Evaluation order: Please update the dmd backend

On Wednesday, 2 April 2014 at 08:50:17 UTC, Johannes Pfau wrote: Am Wed, 02 Apr 2014 07:47:23 + schrieb Sarath Kodali sar...@dummy.com: On Tuesday, 1 April 2014 at 22:04:43 UTC, Timon Gehr wrote: On 04/01/2014 08:40 PM, Sarath Kodali wrote: ... The evaluation order of assign operators

Re: [GDC] Evaluation order: Please update the dmd backend

: ... The evaluation order of assign operators should not be LTR as they have right associativity. In a = b = c, c has to be evaluated first, then b and then a. Similarly, in a = b + c, b+c has to be evaluated first before a is evaluated. Otherwise it will be very confusing, that in some

  1   2   >