RFC: scope and borrowing

[Manu via Digitalmars-d]

On 22 September 2014 19:22, via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

> On Sunday, 21 September 2014 at 11:37:19 UTC, Manu via Digitalmars-d wrote:
>
>> On 21 September 2014 16:02, deadalnix via Digitalmars-d <
>> digitalmars-d at puremagic.com> wrote:
>>
>>  On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright wrote:
>>>
>>>  On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:
>>>>
>>>>  What happens when a scope() thing finds it's way into generic code? If
>>>>> the type
>>>>> doesn't carry that information, then you end up in a situation like
>>>>> ref.
>>>>> Have
>>>>> you ever had to wrestle with ref in generic code?
>>>>> ref is the biggest disaster zone in D, and I think all it's problems
>>>>> will
>>>>> translate straight to scope if you do this.
>>>>>
>>>>>
>>>> I'm unaware of this disaster zone.
>>>>
>>>>
>>> Well it is very real. I had to duplicate bunch of code in my visitor
>>> generator recently because of it. Getting generic code ref correct is
>>> very
>>> tedious, error prone, and guarantees code duplication and/or various
>>> static
>>> ifs all over the place.
>>>
>>>
>> It's also extremely hard to unittest; explodes the number of static if
>> paths exponentially. I'm constantly finding bugs appear a year after
>> writing some code because I missed some static branch paths when
>> originally
>> authoring.
>>
>
> If I understand you right, your problems come from the fact that sometimes
> in a template you want ref, and sometimes you don't.
>
> 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.
>
> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/d5ce13f6/attachment.html>