On 10 April 2013 12:40, kenji hara <k.hara.pg@gmail.com> wrote:
2013/4/10 Zach the Mystic <reachzach@gggggmail.com>
On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
http://wiki.dlang.org/DIP36

// Does not pretend to be @safe any more
void test2(ref A a) {
}

I believe 'ref' still *can* be @safe. The unsafe action is really when you assign it to a global pointer.

void test2(ref A a) {
  static A* p;
  p = &a; // <-- This is really the only unsafe thing
}

I think for convenience the function must only be considered unsafe if it does the above. Even returning the 'ref' is @safe so long as the *caller* keeps track of what it passes in, according to DIP25.

"Following limitation apply to scope ref function parameters (including in ref):
...3. Parameter can only be used as an argument for other function if it also accepts scope ref, no implicit casting away."

The DIP fails to mention that 'scope' by itself implies 'ref', and (presumably) can be reserved for cases where the caller specifically does not want to allow rvalue temps. 'scope' implies 'ref' because value types are inherently @safe and need no attributes. I'm not sure what's so bad about allowing 'scope ref' arguments to be passed to 'scope' parameters also. It passes the ref it receives, but since it's still 'scope', it's not going anywhere.

Also, given that 'scope' implies 'ref', there may be significant advantage in simply allowing *all* scope parameters to accept rvalue temps. It would be helpful to have a use case where 'scope' was clearly desired but rvalue temps clearly *not* desired. In most cases, it seems, anything marked 'scope' could easily accept an rvalue temp no problem.

The 'scope ref' syntax does have a slight conflict with DIP25 and my suggested addition DIP35, in that if other means are found to making returning 'ref' safe, 'scope ref' as a syntax means that no rvalue temporary can ever be returned. Since this may be perfectly acceptable from a 'bad practices' point of view, 'scope ref' may still be a good syntax. But if it were seen as okay to return even a an rvalue temporary, since it is made safe by other means, 'scope ref' would either not be usable for this or would actually be (confusingly) returnable.

I think having both 'ref' and 'scope ref' is still reasonable, because:

1. According to DIP25, escaping ref parameter is always safe. But, for rvalue reference, it allows meaningless code.

// Even if this is allowed, it is safe. BUT will introduce bad practice.
ref int foo(scope ref int x) { return x; }

// safe
ref int bar(ref int x) { return x; }

void test() {
    int x;
    foo(x) = 10;    // may useful but...
    foo(1) = 10;    // completely useless!

    bar(x) = 10;    // may useful, and
    bar(1) = 10;    // disallowed.
}

2. Certainly 'scope' by itself _can_ imply 'ref'. BUT, currently a function parameter without 'ref' storage class implies having value semantics (== copy).
If we change the 'scope' meaning to 'implicit ref', it will break the consistency.

Why are you suggesting changing scope to imply ref? This seems wrong. scope and ref are separate, should remain that way.
Arguments would be scope ref, or in ref, thus allowing rvalues. Without ref, I would imagine that the meaning is such that, even though the argument is a copy, it, or members thereof are not allowed to escape.

struct X { int *p; }
int* global;

void func(scope X x) // note: is not ref
{
  global = x.p; // <- error! scope prevents any part of x escaping, even though it's a copy.
}

This way, scope has meaning with or without ref.


And, 'scope' is alredy used for delegate parameter.

int opApply(scope int delegate(ref int) dg);

Such a semantic modification will silently change the meaning of existing code. It's not good to me.

What does scope mean in this case? Is this a conflict in some way?