On Wednesday, 10 April 2013 at 05:21:40 UTC, Manu wrote:
> Why are you suggesting changing scope to imply ref? This seems wrong. scope
> and ref are separate, should remain that way.

To be clear, I suggested it, not Kenji. The reason scope could imply ref is that no value type is ever unsafe. If you copy the value you're passing, there's no way the reference could escape the scope, because there's no reference! A delegate has an implicit pointer and is inherently a reference type, which is why it can work with 'scope'. In all likelihood 'scope' implying 'ref' would needlessly complicate the type system, in exchange for the convenience of only having to type either 'scope' or 'ref' depending on what you wanted. But I suggested it because I at least wanted it to be discussed.

On 10 April 2013 16:11, Zach the Mystic <reachzach@gggggmail.com> wrote:

> On Wednesday, 10 April 2013 at 05:21:40 UTC, Manu wrote:
>
>> Why are you suggesting changing scope to imply ref? This seems wrong.
>> scope
>> and ref are separate, should remain that way.
>>
>
> To be clear, I suggested it, not Kenji. The reason scope could imply ref is that no value type is ever unsafe.


It is though, in the case I demonstrated. A value type can aggregate a
reference type, and by-val scope would prohibit any part of the copy from
escaping in turn.
This is tricky, but I think it would be an important enhancement for
non-ref scope variables and @safe-ty.
It might be impractical, but it's something to think about anyway...

If you copy the value you're passing, there's no way the reference could
> escape the scope, because there's no reference! A delegate has an implicit pointer and is inherently a reference type, which is why it can work with 'scope'. In all likelihood 'scope' implying 'ref' would needlessly complicate the type system, in exchange for the convenience of only having to type either 'scope' or 'ref' depending on what you wanted. But I suggested it because I at least wanted it to be discussed.
>

Fair enough.

On Wednesday, 10 April 2013 at 05:21:40 UTC, Manu wrote:
> 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.

I think this is a subtle point, but I don't think it's correct. I think there's a difference between 'x.p' above, and what '&x.p' or '&x' would give. I think 'scope' should guarantee that you won't assign the *address* of the passed-in parameter:

void func(scope X x, ref X y) {
  static X* xx = &x; // Error
  static int** xpp = &x.p; // Error
  xx = &y; // unsafe, but pass
  xpp = &y.p; // same
}

I don't think it should guarantee that you won't copy something that is *already* a pointer. Copying the pointer may be dangerous, but I don't think 'scope' will be very useful if it's supposed to track the internal pointers of aggregate types like that. I think somebody else has to make sure that pointer is safe. I could be wrong.

On Wednesday, 10 April 2013 at 00:41:54 UTC, kenji hara wrote:
> Why test32 does not accept rvalue like test1? I think that "scope ref"
> should always behave same for rvalue argument - create temporary and take
> its address to "scope ref" parameter. Consistent behavior with any types is
> important for the generic programming.

That is me to blame. I have convinced Namespace that this is the way to go in private conversation and hope to do the same with you ;)

Consistent behavior is important but it does not change the fact that there two types of rvalues in the language - raw literals (42, A.init) and constructed temporaries (A()). Accepting rvalues of the first type in as mutable references may be consistent from the point of view of syntax by _extremely_ confusing semantics-wise:

void foo(scope ref int x)
{
    x = 32;
}

void main()
{
    foo(42); // erm, 32 is the new 42 or ref is not actually ref?
}

Beauty of "in ref" is that in that case user can't use it in any way that may disclose the fact the temporary variable for non-adressable entities is created. For mutable scope ref it is not the case and we must leak implementation details, which is never good.

Another concern is that if someone tries to pass "42" as a mutable ref, most likely he does not really wants it to be mutable and "in ref" is a better match.

This may not be consistent from the point of view of generic code, but it is now consistent from the point of view of programmer : A(...) construct always create temporaries, raw value literals never do (well, they will for "in ref" but you can't observe it). I think this is much more important.

One extra thing to note is that test32 may actually work if it instantiates T as "const int" for 42 (making it "in ref" essentially), but I don't know if D rules allow it.

On Wednesday, 10 April 2013 at 01:40:49 UTC, Zach the Mystic wrote:
> 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.

Safety of "ref" is not problem that this DIP tries to solve. It should be solved with DIP25. Now ref is not safe (despite the fact it pretends to) and it still won't be after DIP36 approval, not until issue is addressed in DIP25.

No need to mix it.

On Wednesday, 10 April 2013 at 05:01:12 UTC, Manu wrote:
> YES PLEASE!!
> I've been saying precisely this for years, I'm glad someone took the time
> to write it down all nice and proposal-like :)

When I initially volunteered to help formalize it I had no strong feelings about this proposal but after taking care of all details I really like how it naturally fits into existing D type system, with no ugly hacks or weird behavior changes.

On Wednesday, 10 April 2013 at 07:46:41 UTC, Dicebot wrote:
> On Wednesday, 10 April 2013 at 01:40:49 UTC, Zach the Mystic wrote:
>> 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.
>
> Safety of "ref" is not problem that this DIP tries to solve. It should be solved with DIP25. Now ref is not safe (despite the fact it pretends to) and it still won't be after DIP36 approval, not until issue is addressed in DIP25.
>
> No need to mix it.

My proposed DIP35 uses 'scope' to enhance DIP25. I don't believe DIP25 is really complete. 'scope' would help it a lot, but that would give more meanings to 'scope' which are potentially in conflict with it just meaning rvalue temp.

On Wednesday, 10 April 2013 at 09:26:38 UTC, Zach the Mystic wrote:
> On Wednesday, 10 April 2013 at 07:46:41 UTC, Dicebot wrote:
>> On Wednesday, 10 April 2013 at 01:40:49 UTC, Zach the Mystic wrote:
>>> 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.
>>
>> Safety of "ref" is not problem that this DIP tries to solve. It should be solved with DIP25. Now ref is not safe (despite the fact it pretends to) and it still won't be after DIP36 approval, not until issue is addressed in DIP25.
>>
>> No need to mix it.
>
> My proposed DIP35 uses 'scope' to enhance DIP25. I don't believe DIP25 is really complete. 'scope' would help it a lot, but that would give more meanings to 'scope' which are potentially in conflict with it just meaning rvalue temp.

And how it is relevant to DIP36? It solves specific issue. It provides some hints how other DIP may use new opportunities. It is up to DIP25 and DIP35 to be built on top if this gets accepted first. Or other way around.

DIPs are built in context for current language implementation, not some potential other DIPs.

On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
> http://wiki.dlang.org/DIP36

I see no point in adding that much complexity for something that can mostly be automated.

On Wednesday, 10 April 2013 at 11:36:22 UTC, deadalnix wrote:
> On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
>> http://wiki.dlang.org/DIP36
>
> I see no point in adding that much complexity for something that can mostly be automated.

Can you explain this a bit more extensively, probably with some sort of counter-proposal? I can't see where complexity comes from, this DIP introduces literally zero special cases.