No it is not the only difference. "scope ref" (as proposed in DIP35) is more restrictive in usage - can't take address of it, can't return it, can't implicitly cast it to normal ref. It is "scope" primarily and "rvalue ref solution" only secondarily.
With DIP25 these restrictions apply to "ref" as well (with the exception that you CAN return a "ref", but it turns out it would also be safe to return a "scope ref" in those circumstances).
DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD.
Yes, the "addressof" part of DIP25 would cause problems, but the part to do with safety of "ref" will not. IMO we shouldn't start trying to add rvalue references until we've solved the safety of normal references. We should therefore split DIP25 into two parts:
- The part that guarantees safety of "ref" can be implemented right away (just make taking the address of a reference unsafe instead of adding "addressof"). There is simply no avoiding implementing something like this if you want safe references.
- The part to do with fixing syntactic ambiguities of &, adding "addressof" and making "ref" more restrictive can be a separate DIP. This is the one that would potentially break code.
If we do this first, the issue of rvalue references becomes a non-issue. Even without explicitly defining what the lifetime of an rvalue reference is it becomes safe to pass them as "ref":
- In DIP25 it is the caller who enforces the safety of "ref", the callee just has to follow the same simple rules.
- The caller will always know the lifetime of anything it passes in, so it is simple to ensure that it doesn't last beyond that.
Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'.
That's not what I'm saying, even with no inference on behalf of the compiler there is still no difference between "scope ref" and "ref".
