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/xdjsmwocbtxovjnat...@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.
