study: use checkedint as a drop-in replacement of native long
mw
mingwu at gmail.com
Tue Aug 18 03:00:35 UTC 2020
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 :-)
More information about the Digitalmars-d
mailing list