<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 September 2014 01:00, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Monday, 22 September 2014 at 12:37:47 UTC, Manu via Digitalmars-d wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
On 22 September 2014 22:14, via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>><br>
wrote:<br>
<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Monday, 22 September 2014 at 11:45:39 UTC, Manu via Digitalmars-d wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Application to scope will be identical to ref. A function that returns or<br>
receives scope that is inserted into generic code must have that property<br>
cascaded outwards appropriately. If typeof() or alias loses 'scope', then<br>
it will all go tits-up.<br>
<br>
</blockquote>
<br>
For receiving it's not necessary, because whether or not the argument is<br>
scoped, the function can always borrow it. The lifetime of its parameter is<br>
narrower than what it gets passed.<br>
<br>
</blockquote>
<br></span><span class="">
It's particularly common in D to produce templates that wrap functions.<br>
If the wrapper doesn't propagate scope outwards, then it can no longer be<br>
called by a caller who borrowed arguments which are to be forwarded to the<br>
function being called. Likewise for return values.<br>
</span></blockquote>
<br>
You have a point there.<br></blockquote><div><br></div><div>It's massive. Trust me, when you're fabricating functions from introspecting other functions, you NEED all these details in the type. If they're not part of the types, then you need to craft lots of junk code to detect that information explicitly, and then you need to branch out n^^2 distinct paths (massive DRY violation) to handle all the combinations.</div><div>Imagine if 'const' was a storage class in the context of generic code... the practicality of that would be identical to 'ref', except that const appears everywhere, and ref appears rarely (probably because people tend to avoid it, because it's broken).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
For return values, the situation is a bit different: They can of course not<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
be assigned to non-scoped variables. But the solution for this simple: the<br>
generic code needs to use scope, too.<br>
</blockquote>
<br>
<br></span><span class="">
This is precisely the problem with ref...<br>
Are you saying that ALL generic code needs to be 'scope' always? That's not<br>
semantically correct.<br>
<br>
</span></blockquote>
<br>
To be clear, I am referring to the implementation, the actual code of the generic functions, not to its signature. The signature of course needs to match the semantics of the generic function.<br></blockquote><div><br></div><div>So...?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I also over-generalized when I said that the return value cannot be assigned to non-scope. It can theoretically depend on the input, though I'm not sure whether it's a good idea to allow this:<br>
<br>
scope!a T scopeFunc(scope T a, scope T b);<br>
<br>
T* genericFunc(T)(T* input1, T* input2) {<br>
...<br>
// this is fine in theory: input1 points to GC or global data<br>
// (because it's not designated as scope)<br>
string temp = scopeFunc(input1, input2);<br>
...<br>
return temp;<br>
}<br>
<br>
Evidently, this generic function cannot accept scoped pointers, thus it can't take advantage of the fact that scopeFunc() does. It's therefore a good idea, to make any generic (and non-generic, too) function take its parameters by scope if at all possible:<br>
<br>
scope!input1 T* genericFunc(T)(scope T* input1, scope T* input2) {<br>
...<br>
scope temp = scopeFunc(input1, input2);<br>
...<br>
return temp;<br>
}<br>
<br>
This second version of the function will work with scope and non-scope inputs alike. More importantly, it doesn't depend on whether it's allowed to assign a scope return value to non-scope if its owners aren't scoped (which I'd like to avoid).<br></blockquote><div><br></div><div>We arrive at yet another case of "it should have been that way from the start" wrt 'scope'.</div><div>The baggage of annotation, and the lack of annotation to existing code is a pretty big pill to swallow.</div><div>If it were just part of the type, there would be no problem, T would already be 'scope T' in the cases where you expect. I can't see any disadvantages there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Now, `genericFunc()` in turn returns a scoped reference, so any other generic code that calls it must again be treated in the same way. Everything else would be unsafe, after all. But note that this only goes as far as an actual scoped value is returned up the call-chain. Once you stop doing so (because you only need to call the scope-returning functions internally for intermediate results, for example), returning scope would no longer be necessary. It still makes sense for these higher-up functions to _accept_ scope, of course, if it's possible.<br>
<br>
Of course, this is only true as long as the generic function knows about the semantics of `scopeFunc()`. Once you're trying to wrap functions (as alias predicates, opDispatch), there needs to be another solution. I'm not sure what this could be though. I see now why you mentioned ref. But the problem is not restricted to ref and scope, it would also apply to UDAs. Maybe, because it is a more general problem independent of scope, the solution needs to be a more general one, too.<br></blockquote><div><br></div><div>I think UDA's are clearly distinct from ref and scope. UDA's can attribute types.</div><div>I strongly believe that the problem is the notion of a 'storage class', it's a faulty concept. It has never yet proven itself be what I've ever wanted in any case I'm aware of.</div><div>Your proposal even implies changes to the concept as it is; like being able to create a local that is 'scope'. Is that a recognition of existing problems? I've been asking for 'ref' local's for half a decade...</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
As far as I can see, there's always a variadic template parameter involved (which is actually a list of aliases in most cases, right?). Would it work if aliases would forward their storage classes, too?</blockquote><div><br></div><div>I'll say, no. It's equally important that is(), typeof(), and type aliasing all work too.<br></div><div>I also think this kinda undermines the notion of a storage class in principle...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Thinking about it, this seems natural, because aliases mean "pass by name".<br></blockquote><div><br></div><div>Types can't be passed to alias parameters. Alias refers to a symbol, not a type.</div><div><br></div><div>Even if this were to be jigged somehow, I think it really just kicks the can forward, and ref/scope is lost somewhere else. I can't imagine ANY situation where I would ever want that information to be lost (unless it was deliberate, like Unqual!), so what's the end goal? We end up in a situation where it's properly passed along everywhere that the information is currently lost... and we have the same thing as if it were just part of the type in the first place?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> A function that returns scope does so for a reason after all.<br>
<br>
<br></span><span class="">
And the generic code can't know what it is. That knowledge must be encoded<br>
in the type system.<br>
<br></span><span class="">
This will work even if the return value of the called function turns out<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
not to be scoped for this particular instantiation. And all this is an<br>
implementation of the generic code, it won't bleed outside, unless the<br>
generic code wants to return the scoped value. In this case, simply apply<br>
the same technique, just one lever higher.<br>
<br>
</blockquote>
<br></span><span class="">
I can't see the solution you're trying to ilustrate, can you demonstrate?<br>
</span></blockquote>
<br>
I hope that the examples above illustrate what I mean. Of course, this doesn't solve the "perfect forwarding" problem, which should maybe be treated separately.<br></blockquote><div><br></div><div>This would be another band-aid to a core problem. D already has plenty of these.</div><div>I hear this "perfect forwarding" concept thrown around, and I think it's another faulty concept. I rarely want 'perfect' forwarding... why would I be forwarding in the first place if it's 'perfect' (there are cases, but not so common)? I almost always want *imperfect* forwarding; that is, some small detail(/s) about the forwarding are manipulated. I think this is the primary case where storage class falls apart in concept.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Maybe you can give counter examples too, if you think it doesn't work.<br>
</blockquote></div><br></div><div class="gmail_extra">It's complex and time consuming to do so. The situations where it all breaks down are often fairly complex (probably why 'ref' as a storage class seems like an okay idea at face value, although I still don't understand the advantage conceptually), and they tend to appear when you don't expect it. My examples with ref above are all practically applicable to scope too though.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Let's turn this around... Why the complexity? Why would you make the change to your proposal to make 'scope' something else outside of the type system? What is the advantage to that complexity. D has no structured method for dealing with that sort of meta, we only have types. Beyond that, it's just spaghetti, as we learn from ref.</div></div>