DIP69 - Implement scope for escape proof references

[Dicebot via Digitalmars-d]

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.

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