On 22 September 2014 22:14, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 22 September 2014 at 11:45:39 UTC, Manu via Digitalmars-d wrote: > >> 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. >> > > For receiving it's not necessary, because whether or not the argument is > scoped, the function can always borrow it. The lifetime of its parameter is > narrower than what it gets passed. > It's particularly common in D to produce templates that wrap functions. If the wrapper doesn't propagate scope outwards, then it can no longer be called by a caller who borrowed arguments which are to be forwarded to the function being called. Likewise for return values. For return values, the situation is a bit different: They can of course not > be assigned to non-scoped variables. But the solution for this simple: the > generic code needs to use scope, too. This is precisely the problem with ref... Are you saying that ALL generic code needs to be 'scope' always? That's not semantically correct. A function that returns scope does so for a reason after all. And the generic code can't know what it is. That knowledge must be encoded in the type system. This will work even if the return value of the called function turns out > not to be scoped for this particular instantiation. And all this is an > implementation of the generic code, it won't bleed outside, unless the > generic code wants to return the scoped value. In this case, simply apply > the same technique, just one lever higher. > I can't see the solution you're trying to ilustrate, can you demonstrate?
