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.
