On Tue, 10 Dec 2024 at 12:26, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

On Monday, 9 December 2024 at 06:57:31 UTC, Manu wrote:
>
> Interesting idea. It seems like a novel solution. Approaching
> it from this perspective feels hard to reason about though...
> it feels like it would add serious friction to introspection
> activities?

How so? Nothing is different in terms of introspection. We
already have friction on how to tell if a call is viable. Other
than that, I don't see a difference here.

-Steve

I think the essence of the issues I imagine stem from the fact that `parseThings` takes on different characteristics (argument attributes change) when/where 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.

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.

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.