www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - study: use checkedint as a drop-in replacement of native long

reply mw <mingwu gmail.com> writes:
(This is a follow-up from the other thread:  
https://forum.dlang.org/thread/rdrqedmbknwrppbfixll forum.dlang.org)


I start this new thread to discuss and improve the usage of 
std.experimental.checkedint
  as a drop-in replacement of native long.

https://dlang.org/phobos/std_experimental_checkedint.html


`Checked` is a struct, try to use it as a `long` require some 
substantial change of existing code that previously use native 
long.

I list 8 things I've found below. Suggestions or PR welcome, e.g. 
even on how to improve the current implementation of `struct 
Checked`, or help from the compiler.

Thanks.


https://github.com/mingwugmail/dlang_tour/blob/master/divbug.d#L38
------------------------------------------------------------------------
alias Long = Checked!long;


void use_checked() {
   long la, lb, lc;  // native
   Long ca, cb, cc;  // checkedint

   // 0. as array literal
   long[] larr = [1, 2, 3];
//Long[] carr = [1, 2, 3];  // Error: cannot implicitly convert 
expression [1, 2, 3] of type int[] to Checked!(long, Abort)[]
   Long[] carr = [checked(1L), checked(2L), checked(3L)];  // more 
verbose

   // 1. checkedint cannot be chain assigned
   la = lb = lc = 0;
//ca = cb = cc = 0;  // Error: expression cc.opAssign(0) is void 
and has no value
   ca = 0;  // have to do separately
   cb = 0;
   cc = 0;

   // 2. have to use .get to call math func
   writeln(std.math.sgn(la));
   writeln(std.math.abs(la));
//writeln(std.math.sgn(ca));  // Error: template std.math.sgn 
cannot deduce function from argument types !()(Checked!(long, 
Abort)), candidates are:
//writeln(std.math.abs(ca));  // Error: template instance 
std.math.abs!(Checked!(long, Abort)) error instantiating
   writeln(std.math.sgn(ca.get));  // need .get
   writeln(std.math.abs(ca.get));  // need .get

   // 3. no opBinaryLeft
   lc = la * lb;
//cc = la * cb;  // Error: can only * a pointer, not a int
   cc = cb * la;  // have to switch order

   // 4. std.conv don't work
   double d = 0;
   lb = d.to!long;
//cb = d.to!Long;  // Error: template instance 
std.conv.to!(Checked!(long, Abort)).to!double error instantiating
   cb = lround(d);

   lb = "0".to!long;
//cb = "0".to!Long; // Error: template std.conv.toImpl cannot 
deduce function from argument types !(Checked!(long, 
Abort))(string), candidates are:
   cb = "0".to!long; // work around ok

   // 5. cannot assign to shared
   static struct S {
     shared long sl;
     shared Long sL;
   }
   S s;
   s.sl = la;
//s.sL = la;  // Error: template 
std.experimental.checkedint.Checked!(long, 
Abort).Checked.opAssign cannot deduce function from argument 
types !()(long) shared, candidates are:
   cast()s.sL = la;  // need the `cast`

   // 6. format %d won't work
   writefln("%04d", la);      // output: 0000
//writefln("%04d", ca);      // Expected '%s' format specifier 
for type 'Checked!(long, Abort)'
   writefln("%s",   ca);      // output: Checked!(long, Abort)(0), 
can this be just be 0?
   writefln("%04d", ca.get);  // output: 0000

   // 7. atomic won't work
   core.atomic.atomicOp!"+="(s.sl, lb);
//core.atomic.atomicOp!"+="(s.sL, cb);  // Error: template 
instance core.atomic.atomicOp!("+=", Checked!(long, Abort), 
Checked!(long, Abort)) error instantiating
//core.atomic.atomicFetchAdd(s.sL, cb);  // Error: template 
core.atomic.atomicFetchAdd cannot deduce function from argument 
types !()(shared(Checked!(long, Abort)), Checked!(long, Abort)), 
candidates are:
}
------------------------------------------------------------------------
Aug 14 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 15, 2020 at 04:28:05AM +0000, mw via Digitalmars-d wrote:
[...]
   // 1. checkedint cannot be chain assigned
   la = lb = lc = 0;
 //ca = cb = cc = 0;  // Error: expression cc.opAssign(0) is void and has no
 value
   ca = 0;  // have to do separately
   cb = 0;
   cc = 0;
This one should be easy to fix. Just change opAssign to return `this` instead of void, and that should solve the problem. [...]
   // 3. no opBinaryLeft
   lc = la * lb;
 //cc = la * cb;  // Error: can only * a pointer, not a int
   cc = cb * la;  // have to switch order
You mean lacking opBinaryRight? That should be simple to implement?
   // 4. std.conv don't work
   double d = 0;
   lb = d.to!long;
 //cb = d.to!Long;  // Error: template instance std.conv.to!(Checked!(long,
 Abort)).to!double error instantiating
   cb = lround(d);
Checked should implement `opCast(T : double)()`.
   lb = "0".to!long;
 //cb = "0".to!Long; // Error: template std.conv.toImpl cannot deduce
 function from argument types !(Checked!(long, Abort))(string), candidates
 are:
   cb = "0".to!long; // work around ok
Add a ctor to Checked that takes a string argument and parses it into a Checked value. [...]
   // 6. format %d won't work
   writefln("%04d", la);      // output: 0000
 //writefln("%04d", ca);      // Expected '%s' format specifier for type
 'Checked!(long, Abort)'
   writefln("%s",   ca);      // output: Checked!(long, Abort)(0), can this
 be just be 0?
   writefln("%04d", ca.get);  // output: 0000
Add an overload of toString that takes a FormatSpec argument: void toString(W,Char)(W sink, FormatSpec!Char fmt) if (isOutputRange!(W, Char)) { if (fmt.spec == "d") { ... /* do the right thing here */ } ... // etc. } These should probably be done as a series of Phobos PRs to improve the usability of Checked. T -- What's a "hot crossed bun"? An angry rabbit.
Aug 14 2020
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
More thoughts:

On Sat, Aug 15, 2020 at 04:28:05AM +0000, mw via Digitalmars-d wrote:
[...]
   // 2. have to use .get to call math func
   writeln(std.math.sgn(la));
   writeln(std.math.abs(la));
 //writeln(std.math.sgn(ca));  // Error: template std.math.sgn cannot deduce
 function from argument types !()(Checked!(long, Abort)), candidates are:
 //writeln(std.math.abs(ca));  // Error: template instance
 std.math.abs!(Checked!(long, Abort)) error instantiating
   writeln(std.math.sgn(ca.get));  // need .get
   writeln(std.math.abs(ca.get));  // need .get
Technically you *could* use `alias this` to decay it to long automatically, then these calls will work. But (1) that runs the risk of implicit conversion accidentally losing the guarantees of Checked when it silently turns into an unwrapped long, thereby defeating the purpose of using Checked; and (2) `alias this` is frowned upon these days because of its complicated relationship with subtyping. One workaround is to write forwarding overloads for these functions as member functions of Checked. But this is D, and we dislike boilerplate, so opDispatch comes to the rescue: struct Checked { ... auto opDispatch(string memb)(Checked arg) if (memb == "sgn" || memb == "abs" || ... /* etc */) { return mixin(memb ~ "(this.get)"); } ... } The bad thing is that you have to manually list the functions. But if then, you could import std.math and use introspection to extract the list of functions automatically. Good opportunity to take advantage of D's metaprogramming capabilities. Start with `__traits(allMembers, std.math)` and go from there. T -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl
Aug 14 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/14/2020 9:28 PM, mw wrote:
 I list 8 things I've found below. Suggestions or PR welcome, e.g. even on how
to 
 improve the current implementation of `struct Checked`, or help from the
compiler.
This is nice work. Thank you! Please file these issues in Bugzilla.
Aug 16 2020
parent reply mw <mingwu gmail.com> writes:
On Sunday, 16 August 2020 at 23:36:51 UTC, Walter Bright wrote:
 On 8/14/2020 9:28 PM, mw wrote:
 I list 8 things I've found below. Suggestions or PR welcome, 
 e.g. even on how to improve the current implementation of 
 `struct Checked`, or help from the compiler.
This is nice work. Thank you! Please file these issues in Bugzilla.
filed here: https://issues.dlang.org/show_bug.cgi?id=21169
Aug 17 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 05:10:01PM +0000, mw via Digitalmars-d wrote:
 On Sunday, 16 August 2020 at 23:36:51 UTC, Walter Bright wrote:
 On 8/14/2020 9:28 PM, mw wrote:
 I list 8 things I've found below. Suggestions or PR welcome, e.g.
 even on how to improve the current implementation of `struct
 Checked`, or help from the compiler.
This is nice work. Thank you! Please file these issues in Bugzilla.
filed here: https://issues.dlang.org/show_bug.cgi?id=21169
You might want to consider splitting up that bug into multiple smaller, more self-contained bugs. Less intimidating that way for potential contributors to fix. ;-) T -- This sentence is false.
Aug 17 2020
parent reply mw <mingwu gmail.com> writes:
On Monday, 17 August 2020 at 17:15:59 UTC, H. S. Teoh wrote:
 On Mon, Aug 17, 2020 at 05:10:01PM +0000, mw via Digitalmars-d 
 wrote:
 
 https://issues.dlang.org/show_bug.cgi?id=21169
You might want to consider splitting up that bug into multiple smaller, more self-contained bugs. Less intimidating that way for potential contributors to fix. ;-)
Was hesitating between splitting or not, then thought user may want to take the full picture into consideration the best approach to fix the issue, e.g. in case one-stone-that-can-kill-multiple-birds. (People can always submit separate a PR to fix one particular issue).
 Chain assignment fix: https://github.com/dlang/phobos/pull/7599
Thanks for the PR, I just added comments: does this fix also work for mixed native & checked chain assignment? i.e. add to unittest: ``` long la, lb; Checked!long ca, cb; la = ca = lb = cb; // mixed chain assign ca = la = cb = lb; ```
Aug 17 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 05:58:16PM +0000, mw via Digitalmars-d wrote:
 On Monday, 17 August 2020 at 17:15:59 UTC, H. S. Teoh wrote:
[...]
 Chain assignment fix: https://github.com/dlang/phobos/pull/7599
Thanks for the PR, I just added comments: does this fix also work for mixed native & checked chain assignment? i.e. add to unittest: ``` long la, lb; Checked!long ca, cb; la = ca = lb = cb; // mixed chain assign ca = la = cb = lb; ```
Currently, it doesn't work. I'm on the fence about whether it should: the whole point of using Checked is that you don't want to automatically convert to the native type because the converted value will lose the protections conferred by Check. Assigning a Checked to a native type *might* be a mistake - you thought the variable was Checked but it wasn't, so subsequent operations on it no longer has Checked semantics even though you thought it does. So I'm not sure this case should be supported. Assigning from Checked back to native should always be explicit IMO (the programmer explicitly indicates he doesn't want Checked protections anymore). T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Aug 17 2020
parent reply mw <mingwu gmail.com> writes:
On Monday, 17 August 2020 at 18:10:16 UTC, H. S. Teoh wrote:
 On Mon, Aug 17, 2020 at 05:58:16PM +0000, mw via Digitalmars-d 
 wrote:
 On Monday, 17 August 2020 at 17:15:59 UTC, H. S. Teoh wrote:
[...]
 Chain assignment fix: 
 https://github.com/dlang/phobos/pull/7599
Thanks for the PR, I just added comments: does this fix also work for mixed native & checked chain assignment? i.e. add to unittest: ``` long la, lb; Checked!long ca, cb; la = ca = lb = cb; // mixed chain assign ca = la = cb = lb; ```
Currently, it doesn't work. I'm on the fence about whether it should: the whole point of using Checked is that you don't want to automatically convert to the native type because the converted value will lose the protections conferred by Check. Assigning a Checked to a native type *might* be a mistake - you thought the variable was Checked but it wasn't, so subsequent operations on it no longer has Checked semantics even though
Yes, that's the principle we all agree. However, we are talking about opAssign() here. The user specifies his/her intention via the variable's type declaration, e.g. native `long` vs checked `Long`. The *subsequent* operations you talking about will be on user specified variable (type), there will be no surprise here: if the LHS is declared as a `long`, the subsequent operations will be on `long`, and if the LHS is `Long`, the subsequent operations will be on `Long`, all as user has specified. opAssign() just make the boxing/unboxing life easier between these two types. And there is not any mathematical operation performed inside opAssign(), hence for this particular function, native == checked is always true. So I think let opAssign() return the underlying type will make the drop-in replacement process more smooth, and without extra correctness concern.
 you thought it does.  So I'm not sure this case should be 
 supported.  Assigning from Checked back to native should always 
 be explicit IMO (the programmer explicitly indicates he doesn't 
 want Checked protections anymore).
Aug 17 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/17/20 4:53 PM, mw wrote:
 On Monday, 17 August 2020 at 18:10:16 UTC, H. S. Teoh wrote:
 On Mon, Aug 17, 2020 at 05:58:16PM +0000, mw via Digitalmars-d wrote:
 On Monday, 17 August 2020 at 17:15:59 UTC, H. S. Teoh wrote:
[...]
 Chain assignment fix: > https://github.com/dlang/phobos/pull/7599
Thanks for the PR, I just added comments: does this fix also work for mixed native & checked chain assignment? i.e. add to unittest: ```   long la, lb;   Checked!long ca, cb;   la = ca = lb = cb;  // mixed chain assign   ca = la = cb = lb; ```
Currently, it doesn't work.  I'm on the fence about whether it should: the whole point of using Checked is that you don't want to automatically convert to the native type because the converted value will lose the protections conferred by Check. Assigning a Checked to a native type *might* be a mistake - you thought the variable was Checked but it wasn't, so subsequent operations on it no longer has Checked semantics even though
Yes, that's the principle we all agree. However, we are talking about opAssign() here. The user specifies his/her intention via the variable's type declaration, e.g. native `long` vs checked `Long`. The *subsequent* operations you talking about will be on user specified variable (type), there will be no surprise here: if the LHS is declared as a `long`, the subsequent operations will be on `long`, and if the LHS is `Long`, the subsequent operations will be on `Long`, all as user has specified. opAssign() just make the boxing/unboxing life easier between these two types. And there is not any mathematical operation performed inside opAssign(), hence for this particular function, native == checked is always true. So I think let opAssign() return the underlying type will make the drop-in replacement process more smooth, and without extra correctness concern.
Whenever I implement opAssign I have it return void and try to remember to propose that the compiler takes care of chained assignments by itself. Requiring user-defined assignment to `return *this;` was goofy in C++. Requiring user-defined assignment to `return this;` is goofy in D. Assignment should return void and the compiler should take care of it.
Aug 17 2020
next sibling parent mw <mingwu gmail.com> writes:
On Tuesday, 18 August 2020 at 01:23:01 UTC, Andrei Alexandrescu 
wrote:
 On 8/17/20 4:53 PM, mw wrote:
 On Monday, 17 August 2020 at 18:10:16 UTC, H. S. Teoh wrote:
 On Mon, Aug 17, 2020 at 05:58:16PM +0000, mw via 
 Digitalmars-d wrote:
 On Monday, 17 August 2020 at 17:15:59 UTC, H. S. Teoh wrote:
[...]
 Chain assignment fix: > 
 https://github.com/dlang/phobos/pull/7599
Thanks for the PR, I just added comments: does this fix also work for mixed native & checked chain assignment? i.e. add to unittest: ```   long la, lb;   Checked!long ca, cb;   la = ca = lb = cb;  // mixed chain assign   ca = la = cb = lb; ```
Currently, it doesn't work.  I'm on the fence about whether it should: the whole point of using Checked is that you don't want to automatically convert to the native type because the converted value will lose the protections conferred by Check. Assigning a Checked to a native type *might* be a mistake - you thought the variable was Checked but it wasn't, so subsequent operations on it no longer has Checked semantics even though
Yes, that's the principle we all agree. However, we are talking about opAssign() here. The user specifies his/her intention via the variable's type declaration, e.g. native `long` vs checked `Long`. The *subsequent* operations you talking about will be on user specified variable (type), there will be no surprise here: if the LHS is declared as a `long`, the subsequent operations will be on `long`, and if the LHS is `Long`, the subsequent operations will be on `Long`, all as user has specified. opAssign() just make the boxing/unboxing life easier between these two types. And there is not any mathematical operation performed inside opAssign(), hence for this particular function, native == checked is always true. So I think let opAssign() return the underlying type will make the drop-in replacement process more smooth, and without extra correctness concern.
Whenever I implement opAssign I have it return void and try to remember to propose that the compiler takes care of chained assignments by itself. Requiring user-defined assignment to `return *this;` was goofy in C++. Requiring user-defined assignment to `return this;` is goofy in D. Assignment should return void and the compiler should take care of it.
Right, the library fix (work-around) is sub-optimal, it's better be fixed by the compiler. Walter, it's your turn :-)
Aug 17 2020
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 09:23:01PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
 Whenever I implement opAssign I have it return void and try to
 remember to propose that the compiler takes care of chained
 assignments by itself.
 
 Requiring user-defined assignment to `return *this;` was goofy in C++.
 Requiring user-defined assignment to `return this;` is goofy in D.
 Assignment should return void and the compiler should take care of it.
+1. Is there an enhancement request for this? As Walter often says, if it's not in bugzilla, it doesn't exist. ;-) T -- If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell
Aug 17 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 8/18/20 1:07 AM, H. S. Teoh wrote:
 On Mon, Aug 17, 2020 at 09:23:01PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
 [...]
 Whenever I implement opAssign I have it return void and try to
 remember to propose that the compiler takes care of chained
 assignments by itself.

 Requiring user-defined assignment to `return *this;` was goofy in C++.
 Requiring user-defined assignment to `return this;` is goofy in D.
 Assignment should return void and the compiler should take care of it.
+1. Is there an enhancement request for this? As Walter often says, if it's not in bugzilla, it doesn't exist. ;-)
https://issues.dlang.org/show_bug.cgi?id=21175 Not holding my breath.
Aug 18 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 18, 2020 at 05:39:42PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
 https://issues.dlang.org/show_bug.cgi?id=21175
 
 Not holding my breath.
If someone can kick up a PR for this, the chances would increase significantly. ;-) T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Aug 18 2020
prev sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 18 August 2020 at 01:23:01 UTC, Andrei Alexandrescu 
wrote:
 Requiring user-defined assignment to `return *this;` was goofy 
 in C++. Requiring user-defined assignment to `return this;` is 
 goofy in D. Assignment should return void and the compiler 
 should take care of it.
Do you mean the compiler should take care of returning *this when opAssign returns void? Because there are some use-cases for opAssign to return something different than `this`, but I cannot remember at the moment what it was. It's a niche case.
Mar 24
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 24 March 2021 at 17:23:00 UTC, Q. Schroll wrote:
 On Tuesday, 18 August 2020 at 01:23:01 UTC, Andrei Alexandrescu 
 wrote:
 Requiring user-defined assignment to `return *this;` was goofy 
 in C++. Requiring user-defined assignment to `return this;` is 
 goofy in D. Assignment should return void and the compiler 
 should take care of it.
Do you mean the compiler should take care of returning *this when opAssign returns void? Because there are some use-cases for opAssign to return something different than `this`, but I cannot remember at the moment what it was. It's a niche case.
Ideally `lhs = rhs` would always evaluate to `lhs`, as it does for the built-in assignment operator. But that would require a deprecation cycle, since, as you say, existing code could be relying on the current behavior.
Mar 24
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 24, 2021 at 05:23:00PM +0000, Q. Schroll via Digitalmars-d wrote:
 On Tuesday, 18 August 2020 at 01:23:01 UTC, Andrei Alexandrescu wrote:
 Requiring user-defined assignment to `return *this;` was goofy in C++.
 Requiring user-defined assignment to `return this;` is goofy in D.
 Assignment should return void and the compiler should take care of it.
Do you mean the compiler should take care of returning *this when opAssign returns void? Because there are some use-cases for opAssign to return something different than `this`, but I cannot remember at the moment what it was. It's a niche case.
I think Andrei meant that opAssign should *always* return void, and the compiler should always automatically make the RHS of `a = b;` its value. More precisely: struct S { ... } S a, b, c; return a = b = c; should be lowered to: struct S { ... } S a, b, c; b.opAssign(c); a.opAssign(b); return a; Having the value of `a = b` return anything other than the RHS of the assignment is goofy semantics. Since there is only one sensible meaning of `a = b = c`, the compiler should just automate it instead of requiring the user to restate the obvious (and potentially making a mistake or introducing goofy semantics that hurt the readability / maintainability of the resulting code). T -- If you're not part of the solution, you're part of the precipitate.
Mar 24
next sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 On Wed, Mar 24, 2021 at 05:23:00PM +0000, Q. Schroll via 
 Digitalmars-d wrote:
 On Tuesday, 18 August 2020 at 01:23:01 UTC, Andrei 
 Alexandrescu wrote:
 Requiring user-defined assignment to `return *this;` was 
 goofy in C++. Requiring user-defined assignment to `return 
 this;` is goofy in D. Assignment should return void and the 
 compiler should take care of it.
Do you mean the compiler should take care of returning *this when opAssign returns void? Because there are some use-cases for opAssign to return something different than `this`, but I cannot remember at the moment what it was. It's a niche case.
I think Andrei meant that opAssign should *always* return void, and the compiler should always automatically make the RHS of `a = b;` its value. More precisely: struct S { ... } S a, b, c; return a = b = c; should be lowered to: struct S { ... } S a, b, c; b.opAssign(c); a.opAssign(b); return a; Having the value of `a = b` return anything other than the RHS
LHS I guess
 of the assignment is goofy semantics. Since there is only one 
 sensible meaning of `a = b = c`, the compiler should just 
 automate it instead of requiring the user to restate the 
 obvious (and potentially making a mistake or introducing goofy 
 semantics that hurt the readability / maintainability of the 
 resulting code).
Does this expand to opIndexAssign and opIndexOpAssign? Because not returning by `ref` is common there and copying is not intended. What about property setters? It sure shouldn't implicitly call the getter -- and even if, a getter need not even exist. Enabling chained assignments isn't as trivial as fixing opAssign. I now know where I've seen an assignment operator not returning a reference to the object: C++'s slice_array and gslice_array[1] have void operator= and the reason probably is that (a) returning the (g)slice_array is conceptually wrong, (b) returning a valarray is wrong, too. Maybe there are constructs in D where the same reasoning applies. [1] https://www.cplusplus.com/reference/valarray/
Mar 24
prev sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined... I think the intent was to not force an order of execution of subexpressions on either side of a single assignment (e.g. a[i] = a[j] with an opIndex implementation), but this seems to leave too much leeway for assignment chains. Side note: having an undefined order of execution of the sides of an assignment can be a great source of fun (read: surprising) bugs in C++. Just going from GCC to clang switches the order around.
Mar 24
next sibling parent mw <mingwu gmail.com> writes:
On Wednesday, 24 March 2021 at 18:38:07 UTC, Gregor Mückl wrote:
 On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined...
Where is the spec you referring to? Let's fix the spec first then.
Mar 24
prev sibling next sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Wednesday, 24 March 2021 at 18:38:07 UTC, Gregor Mückl wrote:
 On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined...
You're probably mistaken. Evaluation order does not mean associating an expression differently. Assignment is right associative in any case: a = b = c is the same as a = (b = c) but when *evaluating* a, b, and c, the compiler can choose to evaluate e.g. b first. It makes more sense if you look at functions retuning by `ref`: int _a, _b, _c; ref int a() { return _a; } ref int b() { return _b; } ref int c() { return _c; } Then, in (parentheses are optional in D) a() = (b() = c()) the compiler could execute b() first, a() second and c() last, getting references (i.e. pointers) and assigning them in the associated way.
Mar 24
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 24 March 2021 at 19:29:54 UTC, Q. Schroll wrote:
 On Wednesday, 24 March 2021 at 18:38:07 UTC, Gregor Mückl wrote:
 On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined...
You're probably mistaken. Evaluation order does not mean associating an expression differently. Assignment is right associative in any case: a = b = c is the same as a = (b = c) but when *evaluating* a, b, and c, the compiler can choose to evaluate e.g. b first. It makes more sense if you look at functions retuning by `ref`: int _a, _b, _c; ref int a() { return _a; } ref int b() { return _b; } ref int c() { return _c; } Then, in (parentheses are optional in D) a() = (b() = c()) the compiler could execute b() first, a() second and c() last, getting references (i.e. pointers) and assigning them in the associated way.
Right, I've made a mistake and confused order of evaluation and associativity in my first look at the spec. Oops :( Still, I think that this part the spec isn't actually well written. I'm mostly referring to the section on order of evaluation, but the rest of this page is also relevant: https://dlang.org/spec/expression.html#order-of-evaluation What I'm missing is a clear statement about operator associativity and operator precedence for expressions. When I'm reading the spec without applying any additional common sense, a + b * c could be evaluated strictly from left to right because I don't see how mathematical operator precedence is explicitly established anywhere. Neither do I see associativity established anywhere. If assignment was clearly defined to be right-associative, things would be unambiguous.
Mar 24
next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 24 March 2021 at 21:38:20 UTC, Gregor Mückl wrote:
 [...]
I'd actually like my claim to be proven wrong. I just can't seem to accomplish that myself ;).
Mar 24
prev sibling parent ag0aep6g <anonymous example.com> writes:
On 24.03.21 22:38, Gregor Mückl wrote:
 What I'm missing is a clear statement about operator associativity and 
 operator precedence for expressions. When I'm reading the spec without 
 applying any additional common sense, a + b * c could be evaluated 
 strictly from left to right because I don't see how mathematical 
 operator precedence is explicitly established anywhere. Neither do I see 
 associativity established anywhere. If assignment was clearly defined to 
 be right-associative, things would be unambiguous.
It's in the grammar. `a + b * c` is parsed as (skipping the boring parts): AddExpression "a" "+" MulExpression "b" "*" "c" And `a = b = c`: AssignExpression "a" "=" AssignExpression "b" "=" "c"
Mar 24
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 24, 2021 at 06:38:07PM +0000, Gregor Mckl via Digitalmars-d wrote:
 On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined...
Link to spec please? If what you say is true, that sounds like an error in the spec. Walter has said many times that evaluation order in D is left to right, unless otherwise indicated. Having it unspecified just leads to a huge can o' worms. [...]
 Side note: having an undefined order of execution of the sides of an
 assignment can be a great source of fun (read: surprising) bugs in
 C++. Just going from GCC to clang switches the order around.
Exactly, this is why Walter is against having unspecific order of execution. This supposed "optimization opportunity" leads to far more trouble than it's worth. T -- What doesn't kill me makes me stranger.
Mar 24
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 24 March 2021 at 21:28:24 UTC, H. S. Teoh wrote:
 On Wed, Mar 24, 2021 at 06:38:07PM +0000, Gregor Mückl via 
 Digitalmars-d wrote:
 On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined...
Link to spec please? If what you say is true, that sounds like an error in the spec. Walter has said many times that evaluation order in D is left to right, unless otherwise indicated. Having it unspecified just leads to a huge can o' worms.
See point 1 under "Implementation Defined": https://dlang.org/spec/expression.html#order-of-evaluation "The order of evaluation of the operands of AssignExpression."
Mar 24
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 24, 2021 at 09:40:07PM +0000, Gregor Mckl via Digitalmars-d wrote:
 On Wednesday, 24 March 2021 at 21:28:24 UTC, H. S. Teoh wrote:
 On Wed, Mar 24, 2021 at 06:38:07PM +0000, Gregor Mckl via Digitalmars-d
 wrote:
 On Wednesday, 24 March 2021 at 17:38:14 UTC, H. S. Teoh wrote:
 Since there is only one sensible meaning of `a = b = c`...
If I'm reading the spec on expressions right, the compiler is actually free to interpret that as (a = b) = c if it feels particularly adventurous. The evaluation order of assignment operations is explicitly undefined...
Link to spec please? If what you say is true, that sounds like an error in the spec. Walter has said many times that evaluation order in D is left to right, unless otherwise indicated. Having it unspecified just leads to a huge can o' worms.
See point 1 under "Implementation Defined": https://dlang.org/spec/expression.html#order-of-evaluation "The order of evaluation of the operands of AssignExpression."
The keyword here is "operands". The order of evaluation of the *operands* is implementation-defined; the order of the evaluation of the assignment *operators* is from right to left. T -- Only boring people get bored. -- JM
Mar 24
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 17, 2020 at 05:10:01PM +0000, mw via Digitalmars-d wrote:
[...]
 https://issues.dlang.org/show_bug.cgi?id=21169
Chain assignment fix: https://github.com/dlang/phobos/pull/7599 T -- Some days you win; most days you lose.
Aug 17 2020
prev sibling parent Nathan S. <no.public.email example.com> writes:
On Saturday, 15 August 2020 at 04:28:05 UTC, mw wrote:
   // 7. atomic won't work
   core.atomic.atomicOp!"+="(s.sl, lb);
 //core.atomic.atomicOp!"+="(s.sL, cb);  // Error: template 
 instance core.atomic.atomicOp!("+=", Checked!(long, Abort), 
 Checked!(long, Abort)) error instantiating
 //core.atomic.atomicFetchAdd(s.sL, cb);  // Error: template 
 core.atomic.atomicFetchAdd cannot deduce function from argument 
 types !()(shared(Checked!(long, Abort)), Checked!(long, 
 Abort)), candidates are:
 }
 ------------------------------------------------------------------------
I've been taking a crack at fixing some of these issue but I think `atomicOp` is incompatible with the premise of `Checked!T`. Either the Hook won't have the opportunity to intercept the update based on what the result would be or the update won't be atomic. `atomicLoad`, `atomicStore`, and `cas` should be fine though as long as there is no Hook state.
Mar 24