On 12/8/2014 8:25 AM, Dicebot wrote:
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
The difference between 'scope ref' and 'ref' parameters is that the former
cannot be returned by reference.
The difference between 'scope ref' and 'ref' function returns is that the former
cannot be saved by the caller.
You can still safely pass the address of a stack variable by 'ref' - it will not
escape. Under the current proposal, as now, you cannot store a ref by ref, and
cannot take the address of a ref variable.
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++.
It's not because C++ designers are idiots. It inevitably follows from what ref
is. ref grew, brick by brick, into a monster, each brick being inevitable.
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 agree it's a seductively simple idea. The trouble starts happening when you
start when making ref idempotent, when ref can only be at the 'head' of a data
structure, when trying to do type deduction of a ref type (do you get the ref,
or do you look 'through' the ref?), what happens with overloading, etc., and on
and on.
