borrowed pointers vs ref

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Tue May 13 06:36:35 PDT 2014


On Monday, 12 May 2014 at 20:36:10 UTC, Walter Bright 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?

There are 2 `scope` uses to think about. One is storage class and 
in that context `scope` is more of owned / unique pointer. Other 
is parameter qualifier and that one is closer to ref / borrowed 
pointer.

Main problem about making `ref` borrowed pointer is that you will 
need to prohibit storing it in function transitively. This will 
need to become invalid code:

struct A
{
     int* ptr;
}

int* gptr;

void foo(ref A a)
{
     gptr = a.ptr; // error, can't leak borrowed a.ptr into global 
context
}

This feels like too much of a breakage, this is why `scope` (or 
`scope ref`) feels more appropriate.


More information about the Digitalmars-d mailing list