On Monday, 8 December 2014 at 23:05:49 UTC, deadalnix wrote:
> scope(int)[] do not make any sense. The slice cannot outlive its
> content. scope as a flag on expressions/symbols is very useful.

I'd say it strange for directly the opposite reason - pure value type is inherently scope so adding such annotation shouldn't matter in general.

On Monday, 8 December 2014 at 21:07:39 UTC, Walter Bright wrote:
>> But was there any reason why those traits (alien to type qualifiers) were
>> pursued? What is the problem with `ref` simply meaning `non-null pointer` and
>> allowing non-idempotent ref(ref(int))?
>
> Because it isn't just a non-null pointer (and ref's can still be null in C++!), it's an auto-dereferencing pointer.

Don't want to distract from topic that actually matters but would be nice to ask you few more question on topic at some point.

On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote:
> A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'.
>

It can safely be returned if you consider its lifetime as the
intersection of the lifetime of the function's parameter.

On Monday, 8 December 2014 at 23:19:26 UTC, deadalnix wrote:
> On Monday, 8 December 2014 at 20:54:54 UTC, Dicebot wrote:
>> But was there any reason why those traits (alien to type qualifiers) were pursued? What is the problem with `ref` simply meaning `non-null pointer` and allowing non-idempotent ref(ref(int))?
>
> Please no.
>
> when you do int a; and then use a, you always either refer to a,
> to memory storage (lvalue) or a, the value stored in that memory
> (the rvalue).
>
> When doing ref int a = xxx;
>
> You specify that you don't create a new storage for a, but that
> you must consider xxx as an lvalue, and bind the name a to that
> same lvalue.

My thoughts have went totally different direction:

ref(int) a = &xxx; // ok
ref(int) a = xxx; // bad, can't initialize ref from value
ref(int) a = intptr; // ok, implicitly inject assert(intptr)
ref(int) a = null; // bad, can't initialize ref from literal

Now I see how issue may arise because of implicit conversion to matching value type (when passing to as function argument for example) but we do already have structs with `alias this` which may need similar semantics - it needs to be defined anyway.

This is still offtopic. I support attempt to make scope a storage class in general because this is an approach of minimal change and still can be useful. Problem with defining it so that it actually is useful.

Walter Bright:

> Safety by default is outside of the sco[pe (!) of this discussion. Also, you can merely put:
>
>     @safe:
>
> at the beginning of a module and it is now all safe.

If that topic is outside the scope of this discussion, then I have opened an ER on it:
https://issues.dlang.org/show_bug.cgi?id=13838

Bye,
bearophile

On 08/12/2014 15:53, Steven Schveighoffer wrote:
>>    scope ref int foo(ref int x);
>>
>> will do it.
>
> So:
>
> int x;
>
> foo(x) += 1;
>
> will compile?

Yes, because foo's argument is not scope, it can be returned.

On 12/9/14 9:23 AM, Nick Treleaven wrote:
> On 08/12/2014 15:53, Steven Schveighoffer wrote:
>>>    scope ref int foo(ref int x);
>>>
>>> will do it.
>>
>> So:
>>
>> int x;
>>
>> foo(x) += 1;
>>
>> will compile?
>
> Yes, because foo's argument is not scope, it can be returned.

But I thought if you take a reference from the stack, it's inferred as scope? I feel like there's a missing link somewhere if the scope is missing from the parameter.

Will ref just automatically bind to any scoped reference?

What about this:

auto y = &x;

foo(*y) += 1;

-Steve

On 09/12/2014 16:25, Steven Schveighoffer wrote:
> But I thought if you take a reference from the stack, it's inferred as
> scope? I feel like there's a missing link somewhere if the scope is
> missing from the parameter.

I think (with this DIP) values on the stack can safely be passed as a ref parameter, which is a bit more flexible than a scope parameter.

> Will ref just automatically bind to any scoped reference?
>
> What about this:

(for reference:)
int x;
scope ref int foo(ref int x);

> auto y = &x;
>
> foo(*y) += 1;

y gets inferred as scope, but *y is not scope, so it should work.

On Monday, 8 December 2014 at 23:00:05 UTC, deadalnix wrote:
> This is inherently about ownership. I have a proposal about this.
> Scope is about using things without ownership.
>
> Both are linked but different beast.

Not really different. The activation record (stack frame) is conceptually an object. Scoped objects are owned by the activation record. You have the same problem when handing out references to parts of composite objects.

When propagating references down a call chain you can keep track of the associated call-depth, when the call-depth associated with the reference is greater than 0, then it safe to return the reference from a function. Right?

On Tuesday, 9 December 2014 at 19:39:31 UTC, Ola Fosheim Grøstad
wrote:
> On Monday, 8 December 2014 at 23:00:05 UTC, deadalnix wrote:
>> This is inherently about ownership. I have a proposal about this.
>> Scope is about using things without ownership.
>>
>> Both are linked but different beast.
>
> Not really different. The activation record (stack frame) is conceptually an object. Scoped objects are owned by the activation record. You have the same problem when handing out references to parts of composite objects.
>
> When propagating references down a call chain you can keep track of the associated call-depth, when the call-depth associated with the reference is greater than 0, then it safe to return the reference from a function. Right?

That why i say they are linked. I don't think your way of stating
it contradict what I said.

scope allow for manipulation of data without owning them.
Whatever the owner is (be it the stack frame or anything else)
doesn't really matter here.