On Thursday, 11 December 2014 at 12:48:05 UTC, Manu via
Digitalmars-d wrote:
On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On 12/7/2014 6:12 AM, Dicebot wrote:
But from existing cases it doesn't seem working good enough.
For example,
not
being able to represent idiom of `scope ref int foo(scope ref
int x) {
return x;
}` seems very limiting.
scope ref int foo(ref int x);
will do it.
Will it? It looks like foo can't be called with scope data?
This is a point that most people don't seem to understand yet,
and which wasn't obvious for me either, at the beginning:
* A `ref` parameter means that it cannot escape the function,
_except_ by return.
* A `scope ref` parameter means that it cannot escape the
function _ever_, not even by return.
* A `scope ref` return means that it cannot leave the current
statement.
Therefore, a `scope ref` return value can be passed on to the
next function as a `ref` argument. If that function again returns
a reference (even if not explicitly designated as `scope`), the
compiler will treat it as if it were `scope ref`.
I'm also quite uneasy with the fact that scope would not be
transitive
as a storage class. What happens when it's applied to a value
type,
like a struct, that contains some pointers? An adaptation
wrapper for
a single pointer is super common; ie, a tiny struct passed by
value
with scope needs to have it's contained pointer receive the
scope-ness
of the argument.
I agree, this is important. In my proposal, this works without
transitivity. The wrapper stores the pointer as a `scope` member,
then by copying the wrapper, the pointer gets copied implicitly,
to which the normal scope restrictions apply (`scope` on members
means "will not outlive the aggregate"). If it stored it as
normal non-scope pointer, it couldn't get assigned in the first
place. (Additionally, some higher level tricks are possible if we
allow scope for value types and overloading on scope.)
