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