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