<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 10 Dec 2024 at 12:26, Steven Schveighoffer via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, 9 December 2024 at 06:57:31 UTC, Manu wrote:<br>
><br>
> Interesting idea. It seems like a novel solution. Approaching <br>
> it from this perspective feels hard to reason about though... <br>
> it feels like it would add serious friction to introspection <br>
> activities?<br>
<br>
How so? Nothing is different in terms of introspection. We <br>
already have friction on how to tell if a call is viable. Other <br>
than that, I don't see a difference here.<br>
<br>
-Steve<br></blockquote><div><br></div><div>I think the essence of the issues I imagine stem from the fact that `parseThings` takes on different characteristics (argument attributes change) when/<i>where</i> it's CALLED. It means you can't ask hard facts about the type; instead you'd be forced to use more __traits(compiles)-like evaluations to test for compatibility; and I think those are a really bad pattern in general.</div><div>The difference to `inout`; is that it's reliable and detectible at compile time; it assumes the most restrictive traits, because it *could* be called that way... your suggestion seems to be the opposite of that; permissive at compile time, and I can imagine (by guy feeling) that leading to a world of trouble.</div><div>What I suggest with `inout(attrib)` would do the same thing as inout(const) does today; assume the most restrictive thing at compile time so that it's a valid call in all situations.<br></div></div></div>