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