DIP69 - Implement scope for escape proof references

[deadalnix via Digitalmars-d]

On Monday, 8 December 2014 at 16:25:22 UTC, Dicebot wrote:
> 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.
>

That would only ensure that slice do not outline the range.

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

Yes, that is my whole point whith the scope flag in expression.
Without it, the proposal need hacks to work (&(*e)) and is too
restrictive to be useful.

> 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

No, a type constructor is not the right tool. This about it.

scope(int)[] do not make any sense as the slice cannot outlive
its content safely.

You need to have a flag on expression and declarations to make
this work.