Am I wrong in thinking that this is something one would want to do? It seems like it would be useful for the callee to enforce that its return value is assigned to a scope variable.

Currently, it seems like there is some sort of inference of scope on local variables:

struct Test
{
    int n = 3;

    @safe
    int* test() return
    {
        return &n;
    }
}

int* gn;

void main() @safe
{
    Test t;
    int* n = t.test();
    gn = n; //Error: scope variable n assigned to gn with longer lifetime
}

Which is fine, but I'd like to be able to explicitly say, as part of a function's contract, that its result may not be escaped from the caller's scope, and not have to rely on the compiler's inference. The following doesn't work, however, or doesn't work as I'd like it to:

    @safe
    scope int* test() return //Compiles, but doesn't work
    {
        return &n;
    }

    @safe
    scope(int*) test() return //Does not compile; syntax error
    {
        return &n;
    }

On 3/15/2019 10:29 PM, Meta wrote:
> Am I wrong in thinking that this is something one would want to do? It seems like it would be useful for the callee to enforce that its return value is assigned to a scope variable.

Scope on function return values comes from the scope of any arguments passed to the function marked as 'return scope'. Scope on a function return with no such arguments is currently meaningless in D.

To add such a feature, there woul'd need to be compelling use cases.

On Saturday, 16 March 2019 at 17:59:41 UTC, Walter Bright wrote:
> Scope on function return values comes from the scope of any arguments passed to the function marked as 'return scope'. Scope on a function return with no such arguments is currently meaningless in D.
>
> To add such a feature, there woul'd need to be compelling use cases.

Wait, what?

You can apply scope to return values?

I thought in the example above, `scope` applied to the `this` parameter, the same way `return` did?

On Saturday, 16 March 2019 at 17:59:41 UTC, Walter Bright wrote:
> On 3/15/2019 10:29 PM, Meta wrote:
>> Am I wrong in thinking that this is something one would want to do? It seems like it would be useful for the callee to enforce that its return value is assigned to a scope variable.
>
> Scope on function return values comes from the scope of any arguments passed to the function marked as 'return scope'. Scope on a function return with no such arguments is currently meaningless in D.
>
> To add such a feature, there woul'd need to be compelling use cases.

So to be clear, you *can* add scope to the return type of a function, and it will propagate the shortest lifetime among any parameters marked with `return` or `return scope` to the return value? I don't think this is mentioned anywhere in the docs, which is what confused me. I thought that scope on the return type was either a no-op, or that it applied to the function (despite being on the left-hand side). I *think* I can get the effect that I want, given that's how it works. I'll play around a bit and report back.

Also, I'd like to echo the request that you document this stuff. What's already there is fairly useful, but obviously it's not complete.

On Monday, 18 March 2019 at 17:20:37 UTC, Meta wrote:
> On Saturday, 16 March 2019 at 17:59:41 UTC, Walter Bright wrote:
>> On 3/15/2019 10:29 PM, Meta wrote:
>>> Am I wrong in thinking that this is something one would want to do? It seems like it would be useful for the callee to enforce that its return value is assigned to a scope variable.
>>
>> Scope on function return values comes from the scope of any arguments passed to the function marked as 'return scope'. Scope on a function return with no such arguments is currently meaningless in D.
>>
>> To add such a feature, there woul'd need to be compelling use cases.
>
> So to be clear, you *can* add scope to the return type of a function, and it will propagate the shortest lifetime among any parameters marked with `return` or `return scope` to the return value? I don't think this is mentioned anywhere in the docs, which is what confused me. I thought that scope on the return type was either a no-op, or that it applied to the function (despite being on the left-hand side). I *think* I can get the effect that I want, given that's how it works. I'll play around a bit and report back.
>
> Also, I'd like to echo the request that you document this stuff. What's already there is fairly useful, but obviously it's not complete.

As an addendum, are these three member function declarations equivalent (disregard the fact that this would normally cause a duplicate function definition error)?

struct Test
{
    int n = 3;

    @safe
    int* test() return
    {
        return &n;
    }

    @safe
    scope int* test() return
    {
        return &n;
    }

    @safe
    scope int* test() return scope
    {
        return &n;
    }
}

On 3/18/2019 10:20 AM, Meta wrote:
> So to be clear, you *can* add scope to the return type of a function, and it will propagate the shortest lifetime among any parameters marked with `return` or `return scope` to the return value?

No. Adding scope as the storage class of the function means it is attached to the 'this' parameter, if any.

Any 'return scope' parameter to the function will constrict the lifetime of the return value to that of the smallest lifetime of such arguments.


> Also, I'd like to echo the request that you document this stuff. What's already there is fairly useful, but obviously it's not complete.

It can be improved. But my focus at the moment is getting Phobos to compile with -dip1000.

On 3/18/2019 10:22 AM, Meta wrote:
> struct Test
> {
>      int n = 3;
> 
>      @safe
>      int* test() return
>      {
>          return &n;
>      }
> 
>      @safe
>      scope int* test() return
>      {
>          return &n;
>      }
> 
>      @safe
>      scope int* test() return scope
>      {
>          return &n;
>      }
> }
> 

An explicit scope doesn't apply to the returned value, it attaches to the implicit `this` argument.

On Tuesday, 19 March 2019 at 02:03:12 UTC, Walter Bright wrote:
> On 3/18/2019 10:20 AM, Meta wrote:
>> So to be clear, you *can* add scope to the return type of a function, and it will propagate the shortest lifetime among any parameters marked with `return` or `return scope` to the return value?
>
> No. Adding scope as the storage class of the function means it is attached to the 'this' parameter, if any.

Ah, I misinterpreted what you meant when you said "Scope on function return values comes from the scope of any arguments passed to the function marked as 'return scope'."

I pictured this:

scope T* doSomething(return scope T*);

Where the `scope` is attached to the T* return value, not to the function, but I think what you meant was this:

T* doSomething(return scope T*);

scope val = doSomething(someOtherVal);

Right?

> Any 'return scope' parameter to the function will constrict the lifetime of the return value to that of the smallest lifetime of such arguments.

Yes, I've got it now. Thank you.

>> Also, I'd like to echo the request that you document this stuff. What's already there is fairly useful, but obviously it's not complete.
>
> It can be improved. But my focus at the moment is getting Phobos to compile with -dip1000.

Once I get a feel for DIP1000, I can hopefully help with that a bit.

On Tuesday, 19 March 2019 at 02:03:12 UTC, Walter Bright wrote:
> [snip]
>
> It can be improved. But my focus at the moment is getting Phobos to compile with -dip1000.

BTW, did you see this:
https://atilaoncode.blog/2019/03/13/issues-dip1000-cant-yet-catch/

On 3/18/2019 7:22 PM, Meta wrote:
> I think what you meant was this:
> 
> T* doSomething(return scope T*);
> 
> scope val = doSomething(someOtherVal);
> 
> Right?

Yes, except it is unnecessary to mark val as scope. The compiler will attach scope to it automatically if someOtherVal is scope.