Manu have you shown Walter some of the code where ref is problematic? He seems to have asked to see examples repeatedly as he's not convinced there is a problem.

On 11/12/2014 09:07, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> If I as a programmer know that something is safe, then the compiler
> should accept it, and the language should allow me express it.

It will, use @system. Maybe this proposal will be supplemented later, but there are always costs to making the language more complicated. We need to be certain they are worth it before adding them. A cautious approach can be extended later, if the situation demands it.

Sometimes innovative workarounds are developed that are difficult to foresee in advance - e.g. in Rust their type system can be restrictive, but they rely on trusted library functions/types to make more things possible in a safe way.

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`.

> I'm also quite uneasy with the fact that scope would not be transitive
> as a storage class. What happens when it's applied to a value type,
> like a struct, that contains some pointers? An adaptation wrapper for
> a single pointer is super common; ie, a tiny struct passed by value
> with scope needs to have it's contained pointer receive the scope-ness
> of the argument.

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. (Additionally, some higher level tricks are possible if we allow scope for value types and overloading on scope.)

On 09/12/2014 16:25, Steven Schveighoffer wrote:
> Will ref just automatically bind to any scoped reference?

A ref parameter essentially is a scope ref parameter, but it can also be returned:
http://forum.dlang.org/post/m64v3g$2bga$1@digitalmars.com

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`.
>

OH! I had totally misunderstood that. Cheers for the explanation.

On Thursday, 11 December 2014 at 13:43:07 UTC, Nick Treleaven wrote:
> It will, use @system.

Yes…

> Maybe this proposal will be supplemented later, but there are always costs to making the language more complicated. We need to be certain they are worth it before adding them. A cautious approach can be extended later, if the situation demands it.

Can it be extended later? Without breaking stuff?

You need to get it right from the start, otherwise you end up with N different, but incompatible ways of doing the same thing. That means you need to get ownership right first.

Nick Treleaven:

> Sometimes innovative workarounds are developed that are difficult to foresee in advance - e.g. in Rust their type system can be restrictive, but they rely on trusted library functions/types to make more things possible in a safe way.

Ideally a type system should be flexible enough, in practice giving it a high flexibility has significant costs (in compilation times, amount of code that implements the system, bugs in such implementation, costs for the final programmer in inventing a way to express the semantics, etc), so most languages avoid a too much complex type system (even Haskell does this) and accept reasonable workarounds...

Bye,
bearophile

On 12/11/14 8:55 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" 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`.

Please, put this in the DIP! This is exactly the thing I had been asking for here: http://forum.dlang.org/post/m5sitd$1ki0$1@digitalmars.com

Thanks, I'll re-read the proposal with this in mind.

-Steve

On 12/11/2014 4:47 AM, 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?

Yes, it can be.


> I don't have the perfect proposal, but I feel very strongly about 2 things:
> 1. It must not be a storage class; the concept was a disaster with
> ref, and I struggle with this more frequently than any other 'feature'
> in D.

I simply do not understand why distinguishing beteen ref and not-ref is a cornerstone of everything you do.


> 2. I feel it's a big mistake to separate it from the type system,
> which I think most agree, is D's greatest asset by far. Manipulating
> types is simple and convenient using the type system, and I think
> manipulating scope will be just as important as any other attribute as
> soon as even slightly complex use cases begin to arise.

Consider a ref counted type, RC!T. If scope were transitive, then you could not have, say, a tree where the edges were RC!T. I.e., the payload of an RC type should not be forced to be scope.

On 12/11/2014 8:26 AM, Steven Schveighoffer wrote:
> Please, put this in the DIP! This is exactly the thing I had been asking for
> here: http://forum.dlang.org/post/m5sitd$1ki0$1@digitalmars.com
>
> Thanks, I'll re-read the proposal with this in mind.

Marc is clearly better at explaining things than I am, as I've explained that point in this thread about 5 times now.