On Tuesday, 17 March 2015 at 01:13:41 UTC, Zach the Mystic wrote:
On Monday, 16 March 2015 at 20:50:46 UTC, Marc Schütz wrote:
It works just the same:
struct S {
private int* payload_;
ref int* payload() return {
return payload_;
}
}
ref int* payload(scope ref S __this) return {
return __this.payload_; // well, imagine it's not private
}
More accurately,
// `return` is moved
ref int* payload(return scope ref S __this) {
return __this.payload_;
}
Right, copy&paste mistake.
I think that if you need `return` to make it safe, there's much
less need for `scope`.
Both the S.payload() and the free-standing payload() do the
same thing.
From inside the functions, `return` tells us that we're
allowed to a reference to our payload. From the caller's point
of view, it signifies that the return value is scoped to the
first argument, or `this` respectively.
To reiterate, `scope` members are just syntactical sugar for
the kinds of accessor methods/functions in the example code.
There's nothing special about them.
That's fine, but then there's the argument that syntax sugar is
different from "real" functionality. To add it would require a
compelling use case.
My fundamental issue with `scope` in general is that it should
be the safe default, which means it doesn't really need to
appear that often. If @safe is default, the compiler would
force you to mark any parameter `return` when it detected such
a return.
Hmmm... you have a point there. On the other hand, if @safe is
merely inferred (for templates), then you wouldn't get an error,
but it would get inferred @system instead.
