March 14, 2021
On 3/11/2021 5:40 PM, tsbockman wrote:
> I think I finally figure out how to make some sense out of the DIP's description. However, the lowering cannot be expressed clearly with the DIP's syntax, so I will use an alternative notation:
> 
> void moveConstruct(ref S source) nothrow @nogc {
>      if(source.isUnique) {
>          ptr = &internal;
>          internal = source.internal;
>      } else
>          ptr = source.ptr;
> }
> void moveAssign(ref S source) @trusted nothrow @nogc {
>      S oldDest = void;
>      oldDest.moveConstruct(this); // Move the old value to a temporary.
>      moveConstruct(source);
>      // Implicitly destroy the old value.
> }
> 
> Is this correct? If so, the DIP really needs to explain it more clearly - especially if the user is expected to implement some equivalent in the custom move operator himself, rather than the compiler doing it for him.

The idea of the move constructor is the user takes over the task of doing whatever it takes to make it work, i.e. handle the destruction.

Think of it this way. You start with two objects, A and B. Moving B into the storage occupied by A must result in the destruction of the original object occupying A, and whatever is in B after the move is garbage, and what was in B is now in A.

Everything follows from that.
March 15, 2021
On 3/12/2021 4:38 AM, deadalnix wrote:
> On Friday, 12 March 2021 at 10:07:41 UTC, Walter Bright wrote:
>> On 3/11/2021 4:53 PM, deadalnix wrote:
>>> On Thursday, 11 March 2021 at 21:41:59 UTC, Walter Bright wrote:
>>>> Why? There can be no other uses of the rvalue, so why not simply move it?
>>>
>>> If you have two objects in your move constructor, but only one at the end, then a destruction must take place somewhere.
>>
>> The whole point of move construction is to move an initialized object to an unconstructed object. No destruction is needed.
>>
>> It's move assignment that needs to destruct something (the original value of the destination).
> 
> How do you ensures that there aren't any leftover that need to be destroyed or enforce that there are no leftovers?

I don't see any way to do that. When you write a custom destructor, the compiler can't verify it, either.

> Enforcing it seems like an impossible task to be, or at least extremely complex. So that means you need to call the destructor anyways and that forces the struct to have a null state.

Both the move constructor and the destructor are in the same struct, and should be developed at the same time. At some point, the program has to rely on the programmer knowing what he's doing when doing storage management.

March 15, 2021
On 3/13/2021 11:47 AM, 12345swordy wrote:
> On Saturday, 13 March 2021 at 03:06:35 UTC, Walter Bright wrote:
>> On 3/11/2021 10:56 AM, 12345swordy wrote:
>>> How does it handle move constructors when a class have struct type variable that is being alias this?
>>
>> #DIP1040 only applies to structs, not classes.
> 
> That doesn't answer the question.

The question doesn't make a lot of sense, as what does it have to do with classes?


> How does the DIP interact with the current alias this system?
> If I alias this a struct variable with move schematics in struct/class definition called A, does A have the move schematics of the struct variable? Replying "only applied to structs and not classes" isn't helpful here. I am not talking about defining move schematics for classes, I am talking about the class inheriting the struct that has move schematics defined, via alias this.

Classes don't inherit structs. But I will guess at what you mean.

We've discovered that alias this and classes produce a semantic quagmire that every proposed resolution just leads to worse weird cases. Hence:

1. I recommend NEVER using alias this in a class.

2. I'd like to make it illegal.

3. Any questions about how alias this works in a class, I refer to (1).

DIP1040 does not apply to classes. If you have a class that has an alias this that refers to a struct with move semantics, you're going to be sorry :-/

I recommend NEVER using alias this in a class.
March 15, 2021
On 3/13/2021 8:27 PM, tsbockman wrote:
> On Saturday, 13 March 2021 at 19:47:35 UTC, 12345swordy wrote:
>> How does the DIP interact with the current alias this system?
>> If I alias this a struct variable with move schematics in struct/class definition called A, does A have the move schematics of the struct variable?
> 
> According to the DIP, if A does not define explicit custom move operators,

There is no such thing as a "struct/class definition". Structs and classes are different. The DIP defines move semantics for structs, not for classes.
March 15, 2021
On 3/13/2021 5:06 AM, deadalnix wrote:
> The whole notion of move assignement is a hack inherited from C++ and don't really make sense for D.

> As soon as you have 2 objects, you are out of the pure move scenario, and you need to deal with this fact. C++ does so by putting the source object in a null state and then destroying it. You cannot have *2* objects and then not destroy one and expect things to not have a ton of edge cases just like postblit for copy does (because you have the exact same problem in reverse there, you had *1* object when you wanted *2*).

The move assignment has access to both objects, and so can "do the right thing".
March 15, 2021
On Sunday, 14 March 2021 at 01:44:19 UTC, 12345swordy wrote:
> You are making an argument from silence fallacy, if you are asserting that there is no interaction between move semantics with alias this by the virtue of not being mentioning in the dip at all.
>
> - Alex

Alright, can you ensure how there is no interaction with that teapot orbiting around the sun between Mercury and Venus?

Careful because if you don't, you'd be making an argument from silence fallacy, and you sure wouldn't want to do that.

The rest of the sentence pretty much boils down to this: https://i.imgflip.com/51rqyi.jpg

If this is what i wanted to assert, you can trust this is what I would have asserted.
March 15, 2021
On Monday, 15 March 2021 at 13:21:15 UTC, deadalnix wrote:
> On Sunday, 14 March 2021 at 01:44:19 UTC, 12345swordy wrote:
>> You are making an argument from silence fallacy, if you are asserting that there is no interaction between move semantics with alias this by the virtue of not being mentioning in the dip at all.
>>
>> - Alex
>
> Alright, can you ensure how there is no interaction with that teapot orbiting around the sun between Mercury and Venus
> Careful because if you don't, you'd be making an argument from silence fallacy, and you sure wouldn't want to do that.
I am not the one who is making assertions with regards to the DIP based on the virtual of not being mention, you are. Thus your comparisons fails here.

- Alex
March 15, 2021
On Monday, 15 March 2021 at 16:40:27 UTC, 12345swordy wrote:
> On Monday, 15 March 2021 at 13:21:15 UTC, deadalnix wrote:
>> On Sunday, 14 March 2021 at 01:44:19 UTC, 12345swordy wrote:
>>> You are making an argument from silence fallacy, if you are asserting that there is no interaction between move semantics with alias this by the virtue of not being mentioning in the dip at all.
>>>
>>> - Alex
>>
>> Alright, can you ensure how there is no interaction with that teapot orbiting around the sun between Mercury and Venus
>> Careful because if you don't, you'd be making an argument from silence fallacy, and you sure wouldn't want to do that.
> I am not the one who is making assertions with regards to the DIP based on the virtual of not being mention, you are. Thus your comparisons fails here.
>
> - Alex

Meant to say virtue not virtual. Woops

- Alex
March 15, 2021
On Monday, 15 March 2021 at 08:01:02 UTC, Walter Bright wrote:
> On 3/13/2021 11:47 AM, 12345swordy wrote:
>> On Saturday, 13 March 2021 at 03:06:35 UTC, Walter Bright wrote:
>>> On 3/11/2021 10:56 AM, 12345swordy wrote:
>>>> How does it handle move constructors when a class have struct type variable that is being alias this?
>>>
>>> #DIP1040 only applies to structs, not classes.
>> 
>> That doesn't answer the question.
>
> The question doesn't make a lot of sense, as what does it have to do with classes?
>
>
>> How does the DIP interact with the current alias this system?
>> If I alias this a struct variable with move schematics in struct/class definition called A, does A have the move schematics of the struct variable? Replying "only applied to structs and not classes" isn't helpful here. I am not talking about defining move schematics for classes, I am talking about the class inheriting the struct that has move schematics defined, via alias this.
>
> Classes don't inherit structs. But I will guess at what you mean.
>
> We've discovered that alias this and classes produce a semantic quagmire that every proposed resolution just leads to worse weird cases. Hence:
>
> 1. I recommend NEVER using alias this in a class.
>
> 2. I'd like to make it illegal.
>
> 3. Any questions about how alias this works in a class, I refer to (1).
>
> DIP1040 does not apply to classes. If you have a class that has an alias this that refers to a struct with move semantics, you're going to be sorry :-/
>
> I recommend NEVER using alias this in a class.

Then save yourself from future headaches by making it straight up illegal for classes to have alias this a struct that have move schematics. As of now, it is currently possible to have alias this in a class. Which is not going anywhere until someone create a dip that deprecated it. (Which I am 100 percent in favor of btw)

-Alex
March 15, 2021
On Mon, Mar 15, 2021 at 04:51:19PM +0000, 12345swordy via Digitalmars-d wrote:
> On Monday, 15 March 2021 at 08:01:02 UTC, Walter Bright wrote:
[...]
> > 1. I recommend NEVER using alias this in a class.
> > 
> > 2. I'd like to make it illegal.
[...]
> Then save yourself from future headaches by making it straight up illegal for classes to have alias this a struct that have move schematics.
[...]

I'm sure Walter would have made alias this illegal in classes a long time ago, if it were possible without problems.  I'm suspecting the "don't break existing code" bugbear is among the reasons.

I used to be a big fan of alias this, esp. multiple alias this.  Now, after some experience with maintaining code that use alias this willy-nilly, I'm starting to agree with Walter's stance that alias this in general was a bad idea.  Although there are definitely cases for which it's actually useful, the problems it brings along make it of questionable value as a general language feature.  I'd also be in favor of getting rid of it, at least from classes, if not completely. (The latter is probably impossible; quite a lot of my own code relies on it, and I imagine I'm not the only one using it among the users of D.)


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG