2013/4/10 Zach the Mystic <reachz...@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. 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. Kenji Hara