So, what's the story with DIP 1040? It's like 3 or 4 years old, it had community reviews, it appeared to be well received, then... crickets?

Is there a major defect that stalled it?

Walter: Will you consider implementing 1040 as priority? ARM support in DMD is nice to have, but we've been waiting for move semantics for well over a decade... and I really need it, like, asap. It's long overdue.

On 09/07/2024 2:35 PM, Manu wrote:
> So, what's the story with DIP 1040? It's like 3 or 4 years old, it had community reviews, it appeared to be well received, then... crickets?
> 
> Is there a major defect that stalled it?
> 
> Walter: Will you consider implementing 1040 as priority? ARM support in DMD is nice to have, but we've been waiting for move semantics for well over a decade... and I really need it, like, asap. It's long overdue.

The last thing that was said publicly is it went back to Weka to consult on it.

For anything more up to date you need to talk with Mike (I'm sure he'll reply here later).

On Tuesday, 9 July 2024 at 02:40:32 UTC, Richard (Rikki) Andrew Cattermole wrote:

>
> The last thing that was said publicly is it went back to Weka to consult on it.
>
> For anything more up to date you need to talk with Mike (I'm sure he'll reply here later).

Right. So, Weka gave some feedback. Max was going to update the DIP based on their feedback, but ended up moving on from it. I spoke to Walter late last year about picking it up again, and he said he needed time to dig back into it to figure out where it needed to go, but wanted to put it off until later. I was supposed to get back to him about it again a few months later and I never did. So at this point the delay is on me.

So, yes, I know that Walter wanted to get back to it. I'll talk to him about it.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md

We're going to get back on it.

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

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?


> 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?

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.

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.

On 7/14/24 08:44, Richard (Rikki) Andrew Cattermole wrote:
> 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.

Well, I don't think the presented points describe my position.

For the record: I am on board with DIP1040, except for the error-prone design of destructor elision in move constructors and move assignment operators. I think should be explicit.

e.g.

```d
this(S s){
    // perhaps copies some the members of `s` instead of moving them
} // destructor of s called here


```d
this(S s){
    // move out the guts of `s` one by one
    // ...
    ignore(s); // explicitly elide destructor call
}
```

and/or

```d
this(S s){
    // destructure and move:
    this.tupleof = s.moved_tupleof;
    // s is gone here, no destructor will be called
}
```

On 7/14/24 12:39, Timon Gehr wrote:
> ...
> 
> For the record: I am on board with DIP1040, except for the error-prone design of destructor elision in move constructors and move assignment operators. I think should be explicit.
> 

Of course, even more can be done to make move semantics an even better experience in D, but DIP1040 is a good basis. For example, I would want:

- an annotation that ensures a certain use of a variable is a move. (This is important given that the analysis in DIP1040 will need to be incomplete, so it is good to be able to confirm it works where it matters.)

- a parameter storage class that enforces the parameter was moved.

However, those can be pretty easily built on top of DIP1040. (And they may even be the same feature.)