Attribute transference from callbacks?

[Manu]

On Wed, 11 Dec 2024 at 08:41, Zach Tollen via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Sunday, 8 December 2024 at 05:54:40 UTC, Manu wrote:
> > We have a serious problem though; a function that receives a
> > sink function
> > must transfer the attributes from the sink function to itself,
> > and we have
> > no language to do that...
> > What are the leading strategies that have been discussed to
> > date? Is there
> > a general 'plan'?
>
> This was brought up in a [thread][thread1] in DIP Ideas. I
> contributed my idiosyncratic thoughts here:
>
> https://forum.dlang.org/post/rtvjsdyuqwmzwiggsolw@forum.dlang.org
>
> Suggestion #2 in that post addresses the issue you raise. In
> short, I proposed that the language default to inheriting
> attributes for the enclosing function at the call site, and then
> suggested a (callable function/delegate) parameter keyword
> `@noimply` for those rare cases when you *don't* want the
> function to inherit the characteristics of the delegate that you
> pass. I tried to explain it in the post.
>
> All my post did was suggest some hopefully elegant syntax for a
> number of attribute-related issues, of which this was one.
>
> [thread1]:
> https://forum.dlang.org/thread/pfawiqhppkearetcrkno@forum.dlang.org
>

This appears to suffer from the same category of problem as Schveighoffer's
suggestion; it's that you can't reason about the function statically
anymore. Again, the reason I approach it from the perspective of inout(...)
is that you can always statically reason about it, and its guarantees are
appropriately applied at compile time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241212/789146a6/attachment-0001.htm>