On Thursday, 11 December 2014 at 13:55:55 UTC, Marc Schütz wrote:
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
<[email protected]> 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`.
No, it understood. It is simply not useful.
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.
Wut ? You cante store anything with grear lifetime, including non
scope things (as they'll have infinite lifetime). Meaning the
only thing you know, is that thing are possibly scoped.
Meaning you have to assume infinite lifetime with every
indirection, which make this proposal useless.
