DIP 1040

Timon Gehr timon.gehr at gmx.ch
Sun Jul 14 10:25:06 UTC 2024


On 7/13/24 08:36, Richard (Rikki) Andrew Cattermole wrote:
> On 13/07/2024 7:46 AM, Walter Bright wrote:
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md
>>
>> We're going to get back on it.
> 
> We did some reading and reviewing of it last night.
> 
> Some observations:
> 
> 1. It could be simplified greatly if we had type state analysis (blit 
> init over it and be done with it).

Not sure where `.init` enters the picture.

> 2. Its acting in the form of an optimization, rather than trying to be 
> 100% moves only feature.

Well, it has to be backwards-compatible, and it does enable move-only 
types to be used more conveniently.

> 3. Isolated ala Midori could be used instead, and that buys us ownership 
> transfer for temporal safety.

I think this is orthogonal.

> 4. The move constructor isn't great, it is too easily confused. It is 
> closely related to ``opAssign`` so ``opMove`` or ``opAssignMove`` might 
> be better candidates.

I think `this(S s){}` may be okay, but there should be explicit syntax 
to optionally elide the destructor call, so that the constructor does 
not leak anything by accident. By default, a user will most likely 
expect the destructor to be called, as there is nothing special about 
the syntax.



More information about the Digitalmars-d mailing list