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

mw mingwu at gmail.com
Mon Aug 17 20:53:31 UTC 2020


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).




More information about the Digitalmars-d mailing list