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 <
It's also extremely hard to unittest; explodes the number of static ifdigitalmars-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.
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.