DIP 1040
Richard (Rikki) Andrew Cattermole
richard at cattermole.co.nz
Sun Jul 14 06:44:20 UTC 2024
On 14/07/2024 4:51 AM, Walter Bright wrote:
> On 7/12/2024 11:36 PM, 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.
>
> We?
Oh right, me, Paul, Steven and Timon were talking on Discord, if I
remember right.
I can see now that it isn't 6 am, that it may come across as more
official than it is, sorry!
>> Some observations:
>>
>> 1. It could be simplified greatly if we had type state analysis (blit
>> init over it and be done with it).
>> 2. Its acting in the form of an optimization, rather than trying to be
>> 100% moves only feature.
>> 3. Isolated ala Midori could be used instead, and that buys us
>> ownership transfer for temporal safety.
>> 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.
>> 5. To make it move only, you can write and then disable the copy
>> constructor (would need documenting).
>> 6. While it can work, the general consensus seems to be the tunings of
>> the design has some ways to go still.
>
> Consensus of who?
See above, it was the consensus that I saw happening with everyone who
was in the discussion.
But the most important take away is that while there is some questioning
(by myself as to goal), there is nothing that was making us go it can't
go in, in some form.
More information about the Digitalmars-d
mailing list