On 13 May 2014 06:36, Walter Bright via Digitalmars-d <digitalmars-d@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.

On Tue, 2014-05-13 at 04:07 +0000, logicchains via Digitalmars-d wrote: […]
> 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'.

Probably re-finding many of the things people have to use sun.misc.Unsafe for on the JVM.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 13 May 2014 at 04:46:41 UTC, Russel Winder via
Digitalmars-d wrote:
> On Tue, 2014-05-13 at 04:07 +0000, logicchains via Digitalmars-d wrote:
> […]
>> 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'.
>
> Probably re-finding many of the things people have to use
> sun.misc.Unsafe for on the JVM.

Which is why the Java designers are looking on how to make Unsafe
an official package as of Java 9.

And did the survey a few months ago, about how Unsafe was being
used in major Java projects.

--
Paulo

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.

On 13/05/14 15:36, Dicebot wrote:

> 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.

I always though "scope" would behave like that.

-- 
/Jacob Carlborg

On Tuesday, 13 May 2014 at 13:40:42 UTC, Jacob Carlborg wrote:
> On 13/05/14 15:36, Dicebot wrote:
>
>> 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.
>
> I always though "scope" would behave like that.

Walter's initial post implies that he wanted to re-used `ref` for borrowed pointer (which would mean same semantics as `scope` parameter qualifier)

On Tue, 13 May 2014 09:50:12 -0400, Dicebot <public@dicebot.lv> wrote:

> On Tuesday, 13 May 2014 at 13:40:42 UTC, Jacob Carlborg wrote:
>> On 13/05/14 15:36, Dicebot wrote:
>>
>>> 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.
>>
>> I always though "scope" would behave like that.
>
> Walter's initial post implies that he wanted to re-used `ref` for borrowed pointer (which would mean same semantics as `scope` parameter qualifier)

Yes, the difference here is that scope is a storage class, and only affects the "head", whereas borrowed would have to be transitive.

-Steve

On Tuesday, 13 May 2014 at 17:09:17 UTC, Steven Schveighoffer wrote:
> On Tue, 13 May 2014 09:50:12 -0400, Dicebot <public@dicebot.lv> wrote:
>
>> On Tuesday, 13 May 2014 at 13:40:42 UTC, Jacob Carlborg wrote:
>>> On 13/05/14 15:36, Dicebot wrote:
>>>
>>>> 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.
>>>
>>> I always though "scope" would behave like that.
>>
>> Walter's initial post implies that he wanted to re-used `ref` for borrowed pointer (which would mean same semantics as `scope` parameter qualifier)
>
> Yes, the difference here is that scope is a storage class, and only affects the "head", whereas borrowed would have to be transitive.
>
> -Steve

`scope` has to be both storage class and qualifier to work

On 5/13/2014 6:36 AM, Dicebot wrote:
> 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
> }

The lifetime of &a is not at all the same as the lifetime of a.ptr, those are independent pointers. I.e. ref is not transitive (unlike const which is transitive).

On 5/13/2014 6:50 AM, Dicebot wrote:
> Walter's initial post implies that he wanted to re-used `ref` for borrowed
> pointer (which would mean same semantics as `scope` parameter qualifier)

'ref' already is to much extent, for example:

  @safe int foo(ref int x) {
    auto a = &x;
    return 3;
  }

dmd foo -c
foo.d(4): Error: cannot take address of parameter x in @safe function foo