On Tuesday, 2 June 2015 at 17:31:56 UTC, Jonathan M Davis wrote:
On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
Thanks to DIP 25 I think it's time to review this again. I
would implement it (if no one else wants to do it), but there
are still some unanswered questions:
1. Is 'auto ref' still the chosen syntax (I guess so)?
Why not `scope ref` (or `in ref` == `const scope ref`)?
Because scope isn't even properly defined. Certainly, if we
were to go that route, we'd have to finish working out what the
heck scope is really supposed to do and mean. And we haven't
done that yet. As it stands, everyone has their own ideas about
what it means and/or should mean, but all the spec says for
scope parameters is that "references in the parameter cannot be
escaped (e.g. assigned to a global variable)", and right now,
the only thing that scope affects is delegate parameters, and
I'm not sure that even that works correctly yet or is properly
ironed out.
So, while maybe using scope ref for this would make sense, we
have a _lot_ to figure out before we can really consider that.
That's what makes it an ideal choice in my opinion :-) Whatever
semantics we give it is by definition not a breaking change...
Besides, I do have a pretty good idea what `scope` should mean,
including most of the finer details. I summarized it here:
http://wiki.dlang.org/User:Schuetzm/scope3
The lack of progress on this topic is not because no solution is
known.
4. What's with this constellation:
struct S { }
void ene(S) { }
void mene(ref S) { }
void muh(auto ref S) { }
should 'mene' (ref) interfere with 'muh' (auto ref)?
If overloading on `scope` is allowed, then yes, else no.
It's not currently allowed. But regardless, if the whole point
of saying scope ref (or whatever attribute we picked) was to
indicate that we wanted the parameter to accept both lvalues
and rvalues, then it makes no sense whatsoever to overload the
parameter on ref, and it would be ref underneath the hood
anyway, because that's how it would have to be implemented.
There are use-cases for overloading on scope with value types,
but there are other ways to achieve the same goals (see here:
http://wiki.dlang.org/User:Schuetzm/scope3#scope_for_value_types_.26_overloading).
