borrowed pointers vs ref

[Manu via Digitalmars-d]

On 13 May 2014 06:36, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> It's been brought up more than once that the 'scope' storage class is an
> unimplemented borrowed pointer. But thinking a bit more along those lines,
> actually 'ref' fills the role of a borrowed pointer.
>
> One particularly apropos behavior is that struct member functions pass
> 'this' by ref, meaning that members can be called without the inc/dec
> millstone.
>
> ref is still incomplete as far as this goes, but we can go the extra
> distance with it, and then it will be of great help in supporting any ref
> counting solution.
>
> What it doesn't work very well with are class references. But Andrei
> suggested that we can focus the use of 'scope' to deal with that in an
> analogous way.
>
> What do you think?
>
> Anyone want to enumerate a list of the current deficiencies of 'ref' in
> regards to this, so we can think about solving it?

I agree, I think finishing scope appears to deserve a priority boost,
it would be enabling to a lot of developments in D to have reliable
escape analysis.

It seems more problematic to repurpose ref than to finish scope though.
ref would change meaning quite significantly.
ref would probably have to become part of the type (I can imagine
needs for overloads arising?).
You would need to be able to make ref locals, and ref members of
structs so you can do useful work with them.
You'd need to be able to create an array of 'ref's

I think by-value scope still has some value too. A small struct that's
passed by value (like slices) may contain a pointer. You shouldn't
need to handle that small struct by reference when you really just
wanted to attribute it with scope.

I never saw any problems with the scope idea as it stood, and I think
ref is still useful in it's existing incarnation; the same way that
it's useful in C++, ie, a pointer that must be initialised, hides
reassignment and offset/indexing semantics (which can often interfere
with generic code).
extern(C++) would gain a new problem if ref were repurposed.