Attribute transference from callbacks?

[Manu]

On Tue, 10 Dec 2024 at 12:26, Steven Schveighoffer via Digitalmars-d <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241212/5c92b719/attachment.htm>