<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 9 Dec 2024 at 01:51, Timon Gehr 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 12/8/24 06:54, Manu wrote:<br>
> Here's the stupidest idea ever: expand inout to take an argument...<br>
> <br>
> void parseThings(string s, void delegate(Thing) inout(nothrow) <br>
> inout(@nogc) sink) inout(nothrow) inout(@nogc)<br>
> {<br>
>    //...<br>
>    sink(Thing());<br>
>    //...<br>
> }<br>
> ...<br>
<br>
Issue with this is you will still not know which `inout`s match up. This <br>
is already an issue with the existing `inout`, which just arbitrarily <br>
selects a convention. In particular, it does not really work with <br>
higher-order functions the way you'd need it to here.<br></blockquote><div><br></div><div>Yes, this is obviously an issue, and we have it in D comprehensively; it's the main issue with our 'safe' stuff too; where rust has explicit lifetime attribution... it's essentially the same problem all round; it needs tags that specify things which are associated.</div><div>In lieu of that though, I would say, if there are multiple things marked inout(...) in the way I proposed, you would assume the most pessimistic from the set of possibilities is supplied.</div><br></div><div class="gmail_quote gmail_quote_container">
void inheritAttribs(string s, void delegate() inout(nothrow) 


inout(@nogc) fun_1, 
void delegate() inout(nothrow) 


inout(@nogc) fun_2) inout(nothrow) inout(@nogc)<br>{<br>
  //...<br>
  fun_1();<br>


  fun_2();<br>


  //...<br>}</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">In this case, 
`inheritAttribs` would only be nothrow in the event BOTH fun_1 and fun_2 are nothrow, likewise for nogc...</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Surely people have had better ideas? But you get the point, and this is <br>
> basically essential to make the 'sink' pattern work at all in D.<br>
> <br>
> No, no templates; it's not right to generate multiple copies of identical functions just because something it CALLS would transfer an attribute. The function itself is identical no matter the state of any attribute transference, and so this isn't a template problem; it's a pattern matching problem.<br>
<br>
Well, it can be seen as a homogeneous vs heterogeneous compilation <br>
problem. The attributes can still act a bit like template parameters, <br>
but only one instance must be created that works for all of them. It's <br>
sometimes called parametric polymorphism.<br></blockquote><div><br></div><div>Right. Do you have examples of this from other languages and how it's expressed? Lifetime's in Rust are the obvious benchmark, but I don't see any evidence that D has a taste for this sort of thing.<br></div><div><br></div><div>I do think that inout could work for all attributes the same as inout does for const (with the same limitations). You could see `inout` as shorthand for `inout(const)` under my suggestion.</div><div>
<div>Obviously it must enforce the most restrictive 
implementation inside the code; my function 
`inheritAttribs` above must be nothrow and nogc internally, but externally it would allow a mapping 
from one of the 'input' attributes to the 'output' attribute in a 
non-templated way.</div>

</div></div></div>