Bug 8121 – "scope ref" is perfectly OK

void test(scope ref int) { } void main() { } There is nothing wrong with passing something by reference with 'scope', so DMD should compile this.

Also, "scope out" (and even "scope lazy") should also work, since it is perfectly valid for both of them to say, "this parameter will not be escaped".

Does this bug report also cover the case of *returning* scope ref in order to make the following possible: scope ref T opIndex(...); For example in std.container.Array this is helpful in order to write array[0].method() because for by-value opIndex the method() is called on a *copy* of the first element! On the other hand returning by (the usual) ref prevents the container from being a 'sealed container' and hence the restriction would say: "opIndex returns by reference but this reference may not be escaped but only be used to call a method (including operators) on the returned object."

That doesn't make much sense to me... I mean, I agree we need to be able to return scoped values, but given that scope is a storage class, I don't think applying it to a return type makes sense.

*** Issue 10917 has been marked as a duplicate of this issue. ***

scope ref being disallowed made me think that scope must already include ref semantics, because why on earth would someone implement a keyword for references that cannot be used with reference, but only with value semantics ? WAT ?

Right now, scope does _nothing_ except for delegates, and I'm not sure how well it's implemented for them. In all other cases, it's essentially a pointless attribute. It's not even properly defined at this point exactly what scope should mean. We all have a rough idea of what it should mean - that the parameter shouldn't escape the scope of the function - but what exactly that ultimately means has never been properly defined. As such, it really doesn't matter if scope ref is illegal. Arguably, scope on _anything_ other than a delegate should be illegal (the same with in, since it's an alias for const scope), because it does _nothing_ and has yet to be properly defined, meaning that it may or may not do what you expect once it's been properly defined and implemented. So, I think that it's good to take note the compiler currently doesn't allow scope ref for whatever reason so that that can be taken into account when scope is finally ironed out, but until then, it really doesn't matter. I'd strongly argue that if you're using scope on anything other than delegates right now, you should stop, because it has no effect on your code right now but very well could later - and not necessarily how you expect.

The meaning is very clear: This reference is not going to outlive the function scope. The compiler implementation is lacking behind on static checks, but that's not a reason to disallow it or for the current schizophrenic behavior where `scope int*` is allowed but `scope ref int` is an error. (Personally I expect some limited lifetime checks to be coming to D in the future. If just for the sake of passing different pointer types (stack, RC, heap) uniformly to such functions that take scope pointers.)

There has been quite a bit of debate about what it means for a reference to something to escape a function - e.g whether returning something as scope makes sense and counts as not escaping, because the caller can then see that what's being returned was what was being passed in or whether that counts as escaping and should be disallowed. _All_ that the spec says on the matter is "references in the parameter cannot be escaped (e.g. assigned to a global variable)" http://dlang.org/function.html And while you may think that it's clear exactly what that should mean, that doesn't mean that it's actually completely clear and generally accepted as having a particular set of semantics by the community at large or by compiler devs. All we have is the basic idea of what it's supposed to do, and then everyone has their own ideas as to what exactly means, many of which are likely close, but we need to know what the exact semantics are going to be in order to say what does and doesn't make sense, and since it does _nothing_ right now (save for delegates), using scope at all (aside from delegates) is arguably a bad idea. Obviously, you can do whatever you want in your own code, but until scope is properly and fully defined, don't expect things like scope ref to start working if they don't work now. I fully expect that scope is going to get fully hashed out sometime in the near future, because it has the potential of having definite benefits for stuff like reference counting, and that's a priority for Andrei right now, but for now, it wouldn't make any sense to do anything with scope ref. If anything, I'd argue that scope should be an error in all cases except for delegates, because it does _nothing_ for them right now and just risks breaking code once it does.

(In reply to Jonathan M Davis from comment #8) > There has been quite a bit of debate about what it means for a reference to > something to escape a function - e.g whether returning something as scope > makes sense and counts as not escaping, because the caller can then see that > what's being returned was what was being passed in or whether that counts as > escaping and should be disallowed. _All_ that the spec says on the matter is > > "references in the parameter cannot be escaped (e.g. assigned to a global > variable)" > > http://dlang.org/function.html There is no conflict in what you said. What http://dlang.org/function.html says is just supposed to give you an idea what is meant by `scope` in absence of a more narrow and detailed definition. On the discussion about `scope` returns: If it is disallowed no problem. If it is allowed and the compiler has enough information to eventually become sufficiently smart to narrow the lifetime of the result to that of the function arguments it was based on, also fine. Unless someone proposed to legally return `scope` parameters as if they had global lifetime - which I strongly doubt - all is good. > And while you may think that it's clear exactly what that should mean, Yes. > that doesn't mean that it's actually completely clear and generally accepted > as having a particular set of semantics by the community at large or by > compiler devs. But "references in the parameter cannot be escaped (e.g. assigned to a global variable)" is clear enough on the use of `scope`, no matter how the community and compiler devs decide to go on: * We cannot escape references to it by assignments to global variables. * We cannot return them. * We cannot pass them down the call chain, unless the called function's parameter is also `scope`. > All we have is the basic idea of what it's supposed to do, > and then everyone has their own ideas as to what exactly means, many of > which are likely close, but we need to know what the exact semantics are > going to be in order to say what does and doesn't make sense, and since it > does _nothing_ right now (save for delegates), using scope at all (aside > from delegates) is arguably a bad idea. Obviously, you can do whatever you > want in your own code, but until scope is properly and fully defined, don't > expect things like scope ref to start working if they don't work now. As long as I adhere to the three rules above, `scope` _will_ magically start working. Quite some people are using `in` the same way.

(In reply to Marco Leise from comment #9) > As long as I adhere to the three rules above, `scope` _will_ magically start > working. Quite some people are using `in` the same way. I know, which is why I generally tell people not to use in whenever it comes up. Its semantics are not properly defined and are subject to change. You can do whatever you want with scope and risk having your code broken later when scope is actually defined and implemented (though you could get lucky and have used it in a way that's completely consistent with its future implementation), but I strongly argue that there's no point in doing anything with scope ref until the actual semantics of scope have been sorted out, and I'll continue to advise folks not to use scope or in until it's been fully defined and implemented because of the risk it poses.

The provided example compiles now.