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