RFC: scope and borrowing

[Manu via Digitalmars-d]

On 22 September 2014 01:10, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On 9/21/14, 4:27 AM, Manu via Digitalmars-d wrote:
>
>> On 21 September 2014 16:02, deadalnix via Digitalmars-d
>> <digitalmars-d at puremagic.com <mailto: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.
>>
>
> Is this because of problems with ref's definition, or a natural
> consequence of supporting ref parameters? -- Andrei
>

It's all because ref is not part of the type.
You can't capture ref with typeof() or templates, you can't make ref
locals, it's hard to find if something is ref or not (detection is
different than everything else), etc.
The nature of it not being a type leads to static if's in every template
that ref appears, which must detect if things are ref (which is awkward),
and produce multiple paths for a ref and not-ref version. If we're dealing
with arguments, this might lead to num-arguments^^2 paths.

The only practical conclusion I (and others too) have reached, is to
eventually give up and invent Ref!T, but then we arrive at a new world of
problems. It's surprisingly hard to write a transparent Ref template which
interacts effectively with other generic code, and no 3rd party library
will support it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140922/87735984/attachment.html>