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.
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.
- Jonathan M Davis
