On 22 September 2014 01:10, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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@puremagic.com <mailto:digitalmars-d@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.