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.
