<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Oct 2024, 17:10 Walter Bright via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/8/2024 10:42 PM, Manu wrote:<br>
> Can you show us some cases?<br>
<br>
I'd get infinite recursion with overload resolution, because the compiler will <br>
try and match the argument to `S` and `ref S`, made even more complicated with <br>
rvalue references enabled.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't understand; was the argument an rvalue or an lvalue?</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The compiler would go into infinite recursion converting a ref to an rvalue and <br>
back to a ref again. There were maybe 10 or more functions in the recursion <br>
stack, looping through the heavy semantic routines.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Sounds like a an implementation issue/bug... I don't see a semantic issue here?</div><div dir="auto">Consult Razvan, or any other DMD experts?</div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another problem was failure to compile libmir:<br>
```<br>
source/mir/rc/ptr.d(395,15): Error: `mir.rc.ptr.castTo` called with argument <br>
types `(mir_rcptr!(C))` matches both:<br>
source/mir/rc/ptr.d(275,13): `mir.rc.ptr.castTo!(I, <br>
C).castTo(mir_rcptr!(C) context)`<br>
and:<br>
source/mir/rc/ptr.d(291,25): `mir.rc.ptr.castTo!(I, <br>
C).castTo(immutable(mir_rcptr!(C)) context)`<br>
<br>
```<br>
If libmir breaks, that means other code will break, too.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Lol, classic that it presented in rc-ptr! ;)</div><div dir="auto">Again, a specifically stated goal of this work! mir will rewrite to take advantage of the new semantics in a heartbeat!</div><div dir="auto"><br></div><div dir="auto">So far the 2 cases on show are two of the poster-child cases demonstrating exactly why we're doing this!</div><div dir="auto"><br></div><div dir="auto">That aside; why is `(mir_rcptr!(C))` trying to match the immutable one when the exact match is present in the selection set?</div><div dir="auto">The immutable one would require a copy, and construction of an immutable instance from the given mutable instance; certainly not an exact match!</div><div dir="auto">This is an overload selection bug... this is a bug. Why do you present this as a case to abandon the DIP?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I eventually decided it <br>
was not a good idea to modify existing semantics (rvalue constructors exist and <br>
are used already),</blockquote></div></div><div dir="auto"><br></div><div dir="auto">...and this will make them work properly!</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">as who knows how much breakage that would ensue. Adding <br>
distinct syntax for the new semantics seemed like a much more practical approach.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I.e. `this(S)` already is accepted by the compiler and is used.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Precisely why this work is even a thing, and also why you designed your DIP the way you did...</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto">Such examples are the actual point of this work, and they should only benefit...?</div></div>