Move Constructor Syntax (page 7)

On Wednesday, 9 October 2024 at 20:20:02 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 09/10/2024 10:17 PM, RazvanN wrote: >> On Wednesday, 9 October 2024 at 08:38:52 UTC, Jonathan M Davis wrote: >>> On Wednesday, October 9, 2024 12:54:21 AM MDT Manu via >> >> This PR: https://github.com/dlang/dmd/pull/16429 implements the generation of multiple copy constructors as described by Jonathan. It's green and if merged it would alleviate the issues for fields with copy constructors. > > This needs to be talked about at tomorrows meeting (which I might not be at). > > It is a huge benefit. I've already put it on Mike's agenda for the meeting.

On 10/6/2024 5:16 PM, Richard (Rikki) Andrew Cattermole wrote: > There is a very good reason to prefer an attribute rather than new syntax, it doesn't break tooling. True, but an attribute for constructors only seems rather odd.

On 10/9/2024 3:52 AM, Nick Treleaven wrote: > In fact any solution not using the written word 'move' or 'copy' does not have intuitive syntax. I don't understand why anyone is trying to argue that using a sigil in a novel way is intuitive. We have special syntax already for constructors, postblits and destructors. None of it is intuitive - we're just used to it.

On 10/7/2024 9:21 AM, max haughton wrote: > Within the language today what part of a move operation actually requires a new form of constructor? I desperately tried to make `this(S)` a move constructor. I could not find a way that did not break existing code and/or require some rather horrific changes to the complicated logic in the compiler. I explained this earlier - the compiler cannot determine if `this(S)` is a move constructor or not until after semantic analysis. But it needs to know it before semantic analysis. And so the carousel of troubles spins up. Having a distinct syntax simplifies things enormously.

On Thursday, 10 October 2024 at 06:41:00 UTC, Walter Bright wrote:

On 10/9/2024 3:52 AM, Nick Treleaven wrote:

In fact any solution not using the written word 'move' or 'copy' does not have intuitive syntax. I don't understand why anyone is trying to argue that using a sigil in a novel way is intuitive.

We have special syntax already for constructors, postblits and destructors. None of it is intuitive -

we're just used to it.

who is "we"?

you don't value new users?

you don't like fixing past mistakes to make things more consistent?

the only one with special (with a symbol) syntax is the destructor

~this() = 'surf this wave' this()

why cement a bad idea with another symbol, when everything else uses words one can read? and more importantly, search for documentation

do you blindly trust a C++ user? are you a C++ user? do you expect D users to be retired C++ users?

"i am new to D, what is the difference between ~this() "a" ~ "b"

same symbol that does different things

not only symbols without prefix looks ugly, they are also confusing

// Function bodies omitted for brevity // mutable original this(ref typeof(this)); this(ref typeof(this)) const; this(ref typeof(this)) immutable; this(ref typeof(this)) inout; // const original this(ref const typeof(this)); this(ref const typeof(this)) const; this(ref const typeof(this)) immutable; this(ref const typeof(this)) inout; // immutable original this(ref immutable typeof(this)); this(ref immutable typeof(this)) const; this(ref immutable typeof(this)) immutable; this(ref immutable typeof(this)) inout; // inout original this(ref inout typeof(this)); this(ref inout typeof(this)) const; this(ref inout typeof(this)) immutable; this(ref inout typeof(this)) inout; // etc.

October 10

Re: Move Constructor Syntax

Posted by Walter Bright
in reply to Manu

Permalink

Walter Bright

Posted in reply to Manu

Permalink

On 10/8/2024 10:42 PM, Manu wrote:
> Can you show us some cases?

I'd get infinite recursion with overload resolution, because the compiler will try and match the argument to `S` and `ref S`, made even more complicated with rvalue references enabled.

The compiler would go into infinite recursion converting a ref to an rvalue and back to a ref again. There were maybe 10 or more functions in the recursion stack, looping through the heavy semantic routines.

Another problem was failure to compile libmir:
```
source/mir/rc/ptr.d(395,15): Error: `mir.rc.ptr.castTo` called with argument types `(mir_rcptr!(C))` matches both:
  source/mir/rc/ptr.d(275,13):     `mir.rc.ptr.castTo!(I, C).castTo(mir_rcptr!(C) context)`
  and:
  source/mir/rc/ptr.d(291,25):     `mir.rc.ptr.castTo!(I, C).castTo(immutable(mir_rcptr!(C)) context)`

```
If libmir breaks, that means other code will break, too. I eventually decided it was not a good idea to modify existing semantics (rvalue constructors exist and are used already), as who knows how much breakage that would ensue. Adding distinct syntax for the new semantics seemed like a much more practical approach.

I.e. `this(S)` already is accepted by the compiler and is used.

> The story you present is incomplete, let me enhance:
> 
> struct S { ... }
> struct Other { ... }
> 
> this(ref S) // copy constructor
> this(this)  // postblit
> this(S)     // move constructor
> ~this()     // destructor

It's not that simple. You can have:

```
alias T = S;
this(T);     // can't tell if move constructor by syntax
```

> this(Other) // move from other (Other is an rvalue here)
> this(ref Other) // copy from other (Other is obviously a ref)

Problems show up when `Other` is implicitly convertible to `S`.

> Likewise, I don't understand why opMove would be necessary to distinguish from opAssign?

Is `a = b` a move or a copy?

> If you introduce opMove, then you'll end up with opIndexMove, opOpMove, etc.
> Is that something you want? Assuming you want to avoid this; then I also imagine solving for that issue would equally solve for the main constructor case?

This is why I don't like implicit conversions for a struct - you wind up with impossible tangles of meaning. Oh, and rvalue to ref conversions, too.

Forums