DIP69 - Implement scope for escape proof references

[via Digitalmars-d]

On Monday, 8 December 2014 at 16:25:22 UTC, Dicebot wrote:
> On Sunday, 7 December 2014 at 21:29:50 UTC, Walter Bright 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.
>
> This isn't the same as it does not propagate scope but just 
> restricts return value. Difference is that it cannot be 
> chained. Let's consider practical example based on Phobos:
>
> there was an issue with byLine range that it has reused same 
> buffer internally which sometimes caught users off guard when 
> trying to save slice. It is a natural fit for `scope` - make it 
> return `scope string` instead to ensure that no slices get 
> stored.
>
> Two issues immediately pop up:
>
> 1) scope is not transitive thus it doesn't work at all - you 
> still can store slice of `scope string` as only actual 
> ptr+length struct is protected.
>
> 2) even if it worked, existing definition of scope return value 
> makes it impossible to use in typical idiomatic pipeline: 
> `file.byLine.algo1.algo2`. Either algoX is defined to take 
> `scope ref` and thus can't return it or it is defined to take 
> `ref` and can't take another `scope ref` as an argument.

That's why I asked the question in 
http://forum.dlang.org/post/xdjsmwocbtxovjnathek@forum.dlang.org 
. It seems Walter wants to allow passing `scope ref` to `ref`, 
but then automatically treat a normal `ref` of the second 
function as if it were `scope ref`. But I can't quite see through 
it :-(

>
> At least this is what I get from reading existing examples in 
> DIP69
>
>>> I also don't consider `ref` design as a storage class any 
>>> kind of success at all
>>> and generally agree with Manu on this topic. At the same time 
>>> alternative
>>> proposals that make it a qualifier (like Marc did) do impact 
>>> existing language
>>> much more and this no small concern.
>>
>> My experience with C++ ref as type qualifier is very, very 
>> bad. It's a special case EVERYWHERE. Doing type deduction with 
>> it is an exercise in a completely baffling set of rules and a 
>> different rule for every occasion - Scott Meyers has a great 
>> piece on this.
>>
>> There are probably only a handful of people on the planet who 
>> actually understand C++ ref. I wished very hard to avoid that 
>> with D ref.
>
> While there is no argument that C++ ref is screwed, it is 
> rather hard to say if this is inherent consequence of ref being 
> a type qualifier or just C++ being C++. I mean how many C++ 
> type system features in general are understood my more than a 
> handful of people on the planet? For me `ref` is essentially 
> just a different flavor of `*` - and if the latter can be part 
> of type, I see no reasons why former can't

I think most problems would come from type deduction. All the 
other qualifiers and function attributes, like const and pure, 
just either work, or they don't, so they can be tested easily, 
and you want to apply these qualifiers wherever possible. This 
also applies to scope. But for `ref`, it's presence influences 
behaviour, therefore I think it would be best if it were never 
inferred implicitly. Actually that too is just what we do with 
pointers. We don't change non-pointer types to pointers 
automatically.