Move Constructor Syntax

[Manu]

On Sat, 12 Oct 2024 at 03:18, Jonathan M Davis via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Friday, October 11, 2024 9:19:54 AM MDT Manu via Digitalmars-d wrote:
> > The move semantic described by the dip should apply to every rvalue
> > everywhere; they're all potential move targets.
> >
> > Especially so for your weird
> > not-a-move-constructor-but-actually-a-move-constructor that receives T by
> > value; it's the exact definition of a move constructor, and it should be
> > the case that concretely proves that it is also the exact proper syntax
> for
> > the declaration!
>
> Just because a constructor such as this(typeof(this)) looks like a move
> constructor doesn't guarantee that it has those semantics.


It doesn't matter whether it does or doesn't... what the function does is
irrelevant. It's just a function call which can receive a particular
category of argument (r-values) more efficiently than the existing code.
We're really hung up on move constructors, but this DIP is really about
"move semantics", which of course have something to do with move
constructors, but move semantics are so much more than a constructor.

We have no clue
> what the programmer chose to do in that case given that it is not currently
> used as a move constructor and there was zero expectation that it ever
> would
> be.


That's fine, it's welcome to discard the value, nobody's judging. It's
still a constructor, so it must initialise an instance of some kind, and it
only accepts an r-values, so it's something like a move constructor,
whatever it does.

While the obvious use case is to construct the new object with the same
> value as the original, we cannot guarantee that that is what the programmer
> actually did. They could have simply chosen to take parts of the original
> and not the entire thing, using that constructor as a way to pass specific
> parts of the object's state but not all of it, whereas with a move, they
> would want the object to be moved exactly as-is.


I'm getting the impression that you don't really know much about move
semantics. I get the feeling you've made a lot of assumptions which are all
mostly wrong :/

Right now, the programmer
> can rely on that constructor only being called when they've explicitly
> called it, and they're free to do whatever they want with it even if plenty
> of other folks would think that what they did was a bad idea. Changing it
> so
> that that constructor suddenly got called implicitly in a bunch of cases
> would potentially break their code -


Wait... what? Why wouldn't that constructor be callable implicitly?

I can do this:
struct S {
  this(int) {}
}
S s = 10;

That calls an arbitrary constructor implicitly... why is your case
something different?

Can you show any example to your point? I can't imagine it. I think it's
time we understand how this hypothetical thing might get called...?


as well as likely hurting performance,
> since they were presumably fine with the move semantics that they had
> previously and didn't want their constructor called in those cases.
>

Okay, so I think I see your hypothetical case now; some implicitly
generated move might just blit and not call their function? (specifically
because the function is not blessed, and so some internal compiler
generated thing takes precedence?
This is actually THE EXACT REASON I've given for criticising the idea of
blessing special functions... edge cases, edge cases everywhere! People
lean into weird edge cases, often when they don't even intend to or
understand that they have. The language is super non-uniform and full of
nooks and crannies where "weird shit" hang out.

Anyway, I don't think this thing actually exists; even though it's
hypothetically possible, it just doesn't make sense, and it would be
brittle as hell because the compiler would select between its own thing and
the explicitly written thing based on whatever situational takes precedent.
You'll need to show us some cases... if the cases are legit, and not
actually just bugs in random user code, then we can study them.


Another issue here is the refness of the parameter. Move constructors really
> should be taking their argument by ref, not by value, since it's not being
> copied, and it hasn't been moved yet. However, for better or worse,
> this(ref typeof(this)) is already a copy constructor. Having a separate
> syntax for move constructors allows us to have it be =this(ref
> typeof(this))
> or @move this(ref typeof(this)) or whatever, and then it's distinct from
> copy constructors while still having ref like it really should.
> Using this(typeof(this)) while implicitly treating the parameter as ref
> even
> though it isn't just creates a needless special case.
>

This repeats and highlights what I said in my post on the other thread...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241012/f21bc13b/attachment.htm>