[Issue 8121] "scope ref" is perfectly OK

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8121

--- Comment #9 from Marco Leise <Marco.Leise at gmx.de> ---
(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.

--