August 17
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.

August 18
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 :-)


August 17
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
August 18
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.

August 18
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
Next ›   Last »
1 2