The next iteration of scope

[via Digitalmars-d]

On Tuesday, 17 March 2015 at 01:13:41 UTC, Zach the Mystic wrote:
> On Monday, 16 March 2015 at 20:50:46 UTC, Marc Schütz wrote:
>> It works just the same:
>>
>> struct S {
>>    private int* payload_;
>>    ref int* payload() return {
>>        return payload_;
>>    }
>> }
>>
>> ref int* payload(scope ref S __this) return {
>>    return __this.payload_;    // well, imagine it's not private
>> }
>
> More accurately,
>
> // `return` is moved
> ref int* payload(return scope ref S __this) {
>    return __this.payload_;
> }

Right, copy&paste mistake.

>
> I think that if you need `return` to make it safe, there's much 
> less need for `scope`.
>
>> Both the S.payload() and the free-standing payload() do the 
>> same thing.
>>
>> From inside the functions, `return` tells us that we're 
>> allowed to a reference to our payload. From the caller's point 
>> of view, it signifies that the return value is scoped to the 
>> first argument, or `this` respectively.
>>
>> To reiterate, `scope` members are just syntactical sugar for 
>> the kinds of accessor methods/functions in the example code. 
>> There's nothing special about them.
>
> That's fine, but then there's the argument that syntax sugar is 
> different from "real" functionality. To add it would require a 
> compelling use case.
>
> My fundamental issue with `scope` in general is that it should 
> be the safe default, which means it doesn't really need to 
> appear that often. If @safe is default, the compiler would 
> force you to mark any parameter `return` when it detected such 
> a return.

Hmmm... you have a point there. On the other hand, if @safe is 
merely inferred (for templates), then you wouldn't get an error, 
but it would get inferred @system instead.