<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 September 2014 19:22, via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sunday, 21 September 2014 at 11:37:19 UTC, Manu via Digitalmars-d wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 21 September 2014 16:02, deadalnix via Digitalmars-d <<br>
</span><div><div class="h5"><a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What happens when a scope() thing finds it's way into generic code? If<br>
the type<br>
doesn't carry that information, then you end up in a situation like ref.<br>
Have<br>
you ever had to wrestle with ref in generic code?<br>
ref is the biggest disaster zone in D, and I think all it's problems will<br>
translate straight to scope if you do this.<br>
<br>
</blockquote>
<br>
I'm unaware of this disaster zone.<br>
<br>
</blockquote>
<br>
Well it is very real. I had to duplicate bunch of code in my visitor<br>
generator recently because of it. Getting generic code ref correct is very<br>
tedious, error prone, and guarantees code duplication and/or various static<br>
ifs all over the place.<br>
<br>
</blockquote>
<br></div></div><span class="">
It's also extremely hard to unittest; explodes the number of static if<br>
paths exponentially. I'm constantly finding bugs appear a year after<br>
writing some code because I missed some static branch paths when originally<br>
authoring.<br>
</span></blockquote>
<br>
If I understand you right, your problems come from the fact that sometimes in a template you want ref, and sometimes you don't.<br>
<br>
But I think this mostly doesn't apply to scope: either you borrow things, or you don't. In particular, when you do borrow something, you're not interested in the owner your parameter has inside the caller, you just take it by scope (narrowing the lifetime). Thus there needs to be no information about it inside the callee, and you don't need different instantiations depending on it.<br>
<br>
One special case where scope deduction might be desirable are template functions that apply predicates (delegates, lambdas) to passed-in parameters, like map and filter. For these, the scope-ness of the input range can depend on whether the predicates are able to take their parameters as scope.<br>
</blockquote></div><br></div><div class="gmail_extra">Application to scope will be identical to ref. A function that returns or receives scope that is inserted into generic code must have that property cascaded outwards appropriately. If typeof() or alias loses 'scope', then it will all go tits-up.</div></div>