Move Constructor Syntax

[Manu]

On Thu, 10 Oct 2024, 17:10 Walter Bright via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

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

I don't understand; was the argument an rvalue or an lvalue?
It is not at all ambiguous or difficult to select the proper overload
here... one should have been an exact match, the other would have required
a copy or conversion; making it an obviously less preferable match.


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

Sounds like a an implementation issue/bug... I don't see a semantic issue
here?
Consult Razvan, or any other DMD experts?
There's a lot of people who have invested deeply into the complexity of
DMD's semantic passes by now who might be willing to help resolve curly
problems?


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.


Lol, classic that it presented in rc-ptr! ;)
Again, a specifically stated goal of this work! mir will rewrite to take
advantage of the new semantics in a heartbeat!

So far the 2 cases on show are two of the poster-child cases demonstrating
exactly why we're doing this!

That aside; why is `(mir_rcptr!(C))` trying to match the immutable one when
the exact match is present in the selection set?
The immutable one would require a copy, and construction of an immutable
instance from the given mutable instance; certainly not an exact match!
This is an overload selection bug... this is a bug. Why do you present this
as a case to abandon the DIP?


I eventually decided it
> was not a good idea to modify existing semantics (rvalue constructors
> exist and
> are used already),


...and this will make them work properly!

as who knows how much breakage that would ensue. Adding
> distinct syntax for the new semantics seemed like a much more practical
> approach.
>

You're fixing it, not breaking it. I'm not clear what "semantic change" is
actually going on here? It's basically transparent to the language; that's
the whole premise of your design, and the reason why your DIP is genius...
and I'm uncharacteristically enthusiastic about it! :P

It seems like you've either discovered a fundamental fault in your DIP, or
you're just experiencing implementation challenges; which every other DMD
contributor will happily sing in chorus about.


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

Precisely why this work is even a thing, and also why you designed your DIP
the way you did...

There's no change in semantics that I'm aware of; can you show how the
change in calling convention will break these existing calls?
Such examples are the actual point of this work, and they should only
benefit...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241012/085dec64/attachment.htm>