On Wed, 11 Dec 2024 at 08:41, Zach Tollen via Digitalmars-d <digitalmars-d@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.