study: use checkedint as a drop-in replacement of native long
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Tue Aug 18 01:23:01 UTC 2020
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.
More information about the Digitalmars-d
mailing list