On Friday, 12 August 2016 at 12:01:41 UTC, Walter Bright wrote:
> On 8/12/2016 4:12 AM, Joseph Rushton Wakeling wrote:
>> On Thursday, 11 August 2016 at 22:07:57 UTC, Walter Bright wrote:
>>> The scheme does not implement borrowing. References to internal data should be
>>> returned via 'return ref' or 'return scope', where their usage will be limited
>>> to the expression they appear in.
>>
>> I want to make sure we have the same understanding here: the use-case I'm
>> interested in is a data structure that needs to hold a reference to data it does
>> not own -- where, obviously, the lifetime of the data structure cannot outlive
>> the lifetime of the data it references.
>>
>> Surely this scope proposal ought to address that use-case?
>
> Using ref counted objects should deal with that nicely.

I'm not sure I follow.  I'm looking for the ability to guarantee that a pointer to a stack-allocated entity will not go out of scope; I'd rather not have to choose between GC allocation or RC allocation (which I presume would both be on the heap...?).  Or am I missing some of the potential uses of RC?

On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton Wakeling wrote:
> I'm not sure I follow.  I'm looking for the ability to guarantee that a pointer to a stack-allocated entity will not go out of scope

... more precisely, that the pointer will not become invalid because the data it points to goes out of scope.

On 11.08.2016 09:48, Walter Bright wrote:
> On 8/10/2016 11:36 PM, rikki cattermole wrote:
>> Perfect :)
>
> The nice thing about this scheme is it can do some things that Rust
> can't

What are some of those things?

On 8/12/2016 5:54 AM, Joseph Rushton Wakeling wrote:
> On Friday, 12 August 2016 at 12:51:26 UTC, Joseph Rushton Wakeling wrote:
>> I'm not sure I follow.  I'm looking for the ability to guarantee that a
>> pointer to a stack-allocated entity will not go out of scope
>
> ... more precisely, that the pointer will not become invalid because the data it
> points to goes out of scope.
>

That's just what this DIP addresses.

    struct MyWrapperStruct (T)
    {
        private T* data;

        public this (ref T input)
        {
            this.data = &input; // error: not allowed to take address of ref variable
        }
    }

The DIP does not add ownership annotations or semantics.

On 8/12/2016 5:33 AM, Nordlöw wrote:
> If this is successfully implemented, what will D not be able to do, that Rust
> can/will?

Have ownership semantics for pointers in more complex data structures. In D you'll have to do such with ref counted objects.

On the other hand, D code can reference mutable globals in @safe code, whereas Rust cannot.

Assuming, of course, I understood the Rust semantics correctly.

On 8/12/2016 12:03 PM, Timon Gehr wrote:
> On 11.08.2016 09:48, Walter Bright wrote:
>> On 8/10/2016 11:36 PM, rikki cattermole wrote:
>>> Perfect :)
>>
>> The nice thing about this scheme is it can do some things that Rust
>> can't
>
> What are some of those things?

Accessing mutable globals in a function comes to mind.

On 8/12/2016 5:24 AM, Nordlöw wrote:
> On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
>> The first DIP has just landed into the new queue. It is a proposal from
>> language authors and thus it bypasses usual nitpicking process and proceeds
>> straight to requesting community (your!) feedback.
>
> Thanks for all the work.
>
> One remarks. I guess `RefCountedSlice` should infer access permissions of
> `payload` and `count` to allow
>
>     RefCountedSlice!(const(T))
>
> right? Is that beyond the scope of the DIP?

In order for ref counting to work, and because D doesn't support borrowing, the compiler will have to be aware of ref counting. This DIP is necessary for ref counting to work, but is not sufficient, because it doesn't cover how the compiler semantics will work with ref counting.

On 12.08.2016 21:39, Walter Bright wrote:
> On 8/12/2016 5:33 AM, Nordlöw wrote:
>> If this is successfully implemented, what will D not be able to do,
>> that Rust
>> can/will?
>
> Have ownership semantics for pointers in more complex data structures.
> In D you'll have to do such with ref counted objects.
>
> On the other hand, D code can reference mutable globals in @safe code,
> whereas Rust cannot.
>
> Assuming, of course, I understood the Rust semantics correctly.

AFAIU Rust has safe static TLS.

On 8/12/2016 1:08 PM, Timon Gehr wrote:
> On 12.08.2016 21:39, Walter Bright wrote:
>> On 8/12/2016 5:33 AM, Nordlöw wrote:
>>> If this is successfully implemented, what will D not be able to do,
>>> that Rust
>>> can/will?
>>
>> Have ownership semantics for pointers in more complex data structures.
>> In D you'll have to do such with ref counted objects.
>>
>> On the other hand, D code can reference mutable globals in @safe code,
>> whereas Rust cannot.
>>
>> Assuming, of course, I understood the Rust semantics correctly.
>
> AFAIU Rust has safe static TLS.

Perhaps. Rust changes regularly. Some of the top hits in google are out of date.

On Friday, 12 August 2016 at 19:37:47 UTC, Walter Bright wrote:
> That's just what this DIP addresses.
>
>     struct MyWrapperStruct (T)
>     {
>         private T* data;
>
>         public this (ref T input)
>         {
>             this.data = &input; // error: not allowed to take address of ref variable
>         }
>     }
>
> The DIP does not add ownership annotations or semantics.

Unless I've misunderstood you, that doesn't address my use-case -- it outright bans it!

The above code is unsafe only if the lifetime of `data` outlives the lifetime of `input`.  Surely the new scope rules should be able to distinguish the cases?  If that's already envisioned, how would that work?

BTW, the application here is a design that Dicebot and I have been discussing since DConf 2015 to address the concerns related to range implementations of random number generation and random algorithms.