Move Constructor Syntax

[Manu]

On Wed, 9 Oct 2024 at 16:09, Jonathan M Davis via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Tuesday, October 8, 2024 11:42:49 PM MDT Manu via Digitalmars-d wrote:
> > On Sun, 6 Oct 2024 at 14:06, Walter Bright via Digitalmars-d <
> > A fix that would simplify the language and the compiler would be to have
> a
> > > unique syntax for a move constructor, instead of the ambiguous one in
> the
> > > proposal. That way, searching for a copy constructor will only yield
> copy
> > > constructors, and searching for a move constructor will only yield move
> > > constructors. There will be a sharp distinction between them, even in
> the
> > > source
> > > code. (I have seen code so dense with templates it is hard to figure
> out
> > > what
> > > kind of constructor it is.)
> > >
> > > Something like one of:
> > > ```
> > > 1. =this(S)
> > > 2. this(=S)
> > > 3. <-this(S)
> > > ```
> > > ?
> > >
> > > It may take a bit of getting used to. I kinda prefer (1) as it is sorta
> > > like
> > > `~this()`.
> >
> > It's not right to distinguish move constructors, by-value argument is a
> > potential move opportunity.
> > Why aren't the regular parameter matching semantics sufficient? Can you
> > please give us a set of examples where the regular parameter matching
> > semantics are failing or infinite-looping?
>
> Aside from whatever Walter's reasoning is, there are existing constructors
> in the wild which use
>
>     this(S)
>
> to construct a copy of a struct. This allows code such as
>
>     auto s = S(otherS);
>
> and
>
>     auto s = new S(otherS);
>
> to compile. This is particularly useful in generic code where you're
> dealing
> with a variant type, since without that, you have to either use a static if
> branch every time that you construct it in case the variant type is being
> passed in, or you have to create the type with a wrapper function that does
> the static if for you. By just creating a constructor that specifically
> takes the same type (or having a templated constructor which does the
> appropriate static if internally), that issue is avoided. And while it can
> certainly be argued whether that's the best approach, it's an approach that
> exists in the wild today. So, if
>
>     this(S)
>
> suddenly becomes a move constructor, existing code will have a normal
> constructor suddenly turned into a move constructor.
>

Hmmmm. Well, that's not and never was a copy constructor... so are we
required to accept that that was ever correct code?


It's already problematic enough that copy constructors don't have an
> explicit identifier of some kind (which IMHO really should be fixed).
>

What kind of problem is a result of copy constructors not having an
identifier?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241009/0db322b2/attachment-0001.htm>