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

[Q. Schroll]

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/