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
