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 <
[email protected]> 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.
