On 12/11/2014 4:13 PM, deadalnix wrote:
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
<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`.
No, it understood. It is simply not useful.
The use case is described in the DIP under the 'Scope Ref' heading.
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.
It means you'll have to wrap the next level of indirection in a ref counting (or
equivalent) manner.
The great thing about GC is you can leave everything to the GC. But when
explicitly managing memory, you have to decide for EVERY pointer who owns it,
when it can be released, etc. Having a transitive scope is NOT going to resolve
that for you, it isn't even going to help.
