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?

How would you assign a borrowed pointer?

On 5/12/2014 1:49 PM, Kagamin wrote:
> How would you assign a borrowed pointer?

A ref could only be assigned to another ref.

On 5/12/2014 2:13 PM, Walter Bright wrote:
> On 5/12/2014 1:49 PM, Kagamin wrote:
>> How would you assign a borrowed pointer?
>
> A ref could only be assigned to another ref.

I mean to a ref of the same or smaller scope.

On Mon, 12 May 2014 16:36:12 -0400, Walter Bright <newshound2@digitalmars.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.

Hm... the one piece that I think would be damaging is to not be able to take an address of the 'this' reference. It's probably OK to just use pointers and static functions in some cases, but member functions do not have that luxury. In other words, operators.

Big example would be a doubly linked list used with ~=.

-Steve

The first thing that comes to my mind is applying this somehow to the (T) vs (ref T) function problem. (const ref, scope ref, references to r-values, you know the problem.) At the moment I just follow this pattern.

void foo(ref const T bar) {
    /* ... */
}

// Second overload to make r-values just work.
void foo(const T bar) {
    foo(bar);
}

auto ref sometimes works, sometimes it's more trouble than its worth.

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?

I would prefer 'scope ref' that would allow the solution for classes and everything else to be unified, i.e. everything uses scope.

When it comes to the implicit 'this' by ref, it could be redefined to pass by scope ref.

Another reason is: I know this doesn't(and might never) work in D, but based on the intuitive meaning of 'ref' I fully expected the below example to work when I first started learning the language.

struct A
{
  ref int a_m;
  this(ref int a)
  {
    a_m = a;
  }
}

Whereas 'scope' on the other hand is self documenting imho.

On 05/12/2014 10:36 PM, 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?

I think everything should be treated uniformly. But a storage class is not sufficient.

>
> Anyone want to enumerate a list of the current deficiencies of 'ref' in
> regards to this, so we can think about solving it?

Eg:

- Cannot make tail const. / Cannot be reassigned.
- Cannot store in data structures.
- Cannot borrow slices of memory.
- Closures?
- (Probably more)

On 5/12/2014 2:15 PM, Steven Schveighoffer wrote:
> Hm... the one piece that I think would be damaging is to not be able to take an
> address of the 'this' reference. It's probably OK to just use pointers and
> static functions in some cases, but member functions do not have that luxury. In
> other words, operators.
>
> Big example would be a doubly linked list used with ~=.

@trusted/@system code will be able to take the address of a ref.

On Monday, 12 May 2014 at 21:15:38 UTC, Steven Schveighoffer wrote:
> Hm... the one piece that I think would be damaging is to not be able to take an address of the 'this' reference. It's probably OK to just use pointers and static functions in some cases, but member functions do not have that luxury. In other words, operators.
>
> Big example would be a doubly linked list used with ~=.
>
> -Steve

This sounds a bit like an 'issue' of sorts that Rust has with borrowed pointers, where certain types of datastructures cannot be written without resorting to the 'unsafe' parts of the language. The solution they've adopted is having such code written in libraries so that the user doesn't have to mess around with 'unsafe'.