On 8/13/2016 1:13 AM, Joseph Rushton Wakeling wrote:
> 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!

Taking the address of a ref variable has not been allowed in @safe code for a long time.


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

That depends on how the instance of MyWrapperStruct is allocated. How did you intend to allocate it?

On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote:
> Taking the address of a ref variable has not been allowed in @safe code for a long time.

Which is understandable given things as they are, but which could probably be relaxed given good scope/lifetime analysis by the compiler...?

>> 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?
>
> That depends on how the instance of MyWrapperStruct is allocated. How did you intend to allocate it?

As a normal stack variable. Is that problematic? And if not, what would be problematic cases?

On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote:
> On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote:
>> Taking the address of a ref variable has not been allowed in @safe code for a
>> long time.
>
> Which is understandable given things as they are, but which could probably be
> relaxed given good scope/lifetime analysis by the compiler...?

It's relaxed in @system code.


>>> 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?
>>
>> That depends on how the instance of MyWrapperStruct is allocated. How did you
>> intend to allocate it?
>
> As a normal stack variable. Is that problematic?

Shouldn't be.

> And if not, what would be problematic cases?

Allocating it on the heap.

On Saturday, 13 August 2016 at 19:51:07 UTC, Walter Bright wrote:
> On 8/13/2016 5:02 AM, Joseph Rushton Wakeling wrote:
>> On Saturday, 13 August 2016 at 11:09:05 UTC, Walter Bright wrote:
>>> Taking the address of a ref variable has not been allowed in @safe code for a
>>> long time.
>>
>> Which is understandable given things as they are, but which could probably be
>> relaxed given good scope/lifetime analysis by the compiler...?
>
> It's relaxed in @system code.

Sure, but doesn't the envisioned DIP create the circumstances in which it could also be permitted in @safe code where the compiler can guarantee that the pointer's lifetime will not outlive the data referred to?

>>>> 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?
>>>
>>> That depends on how the instance of MyWrapperStruct is allocated. How did you
>>> intend to allocate it?
>>
>> As a normal stack variable. Is that problematic?
>
> Shouldn't be.
>
>> And if not, what would be problematic cases?
>
> Allocating it on the heap.

OK.  I wonder if it might be a good idea for us to discuss my use-case directly some time.  It's quite subtle, and I'm far from sure that I've ironed out all the details or corner-cases in my head, but I think the details of the scope proposal could be very important in determining whether it's workable or not.

The TL;DR here is that I'm concerned about having a solution for random number generators and random algorithms that (i) allows them to be stack-allocated, (ii) ensures that their internal state is not accidentally copied by value, and (iii) allows them to work effectively with (input) range semantics.

On 8/13/2016 1:50 PM, Joseph Rushton Wakeling wrote:
> Sure, but doesn't the envisioned DIP create the circumstances in which it could
> also be permitted in @safe code where the compiler can guarantee that the
> pointer's lifetime will not outlive the data referred to?

The whole point of ref is that it is a special pointer. If you want pointers, use pointers instead. I don't see much value in making ref just an alternative syntax to *.


> OK.  I wonder if it might be a good idea for us to discuss my use-case directly
> some time.  It's quite subtle, and I'm far from sure that I've ironed out all
> the details or corner-cases in my head, but I think the details of the scope
> proposal could be very important in determining whether it's workable or not.
>
> The TL;DR here is that I'm concerned about having a solution for random number
> generators and random algorithms that (i) allows them to be stack-allocated,
> (ii) ensures that their internal state is not accidentally copied by value, and
> (iii) allows them to work effectively with (input) range semantics.

It would be good if your case worked with the scheme, but it is not a disaster if it does not. The DIP closes severe and obvious safety holes, and we need this regardless. There will always be desirable cases that are safe but are not allowed by a scheme, and we have @system for that.

I'm sure we'll find them after this DIP has seen some use for a while.

On Saturday, 13 August 2016 at 20:50:53 UTC, Joseph Rushton Wakeling wrote:
> The TL;DR here is that I'm concerned about having a solution for random number generators and random algorithms that (i) allows them to be stack-allocated, (ii) ensures that their internal state is not accidentally copied by value, and (iii) allows them to work effectively with (input) range semantics.

Isn't it what a scoped class is supposed to provide?

class Rnd {}

void foo() {
  scope rnd  = new Rnd; // reference semantic and stack allocated
}

On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote:
> Isn't it what a scoped class is supposed to provide?
>
> class Rnd {}
>
> void foo() {
>   scope rnd  = new Rnd; // reference semantic and stack allocated
> }

Does that actually work in D2? I thought it was a D1-only thing.

On 8/14/2016 9:56 PM, Joseph Rushton Wakeling wrote:
> Does that actually work in D2?

Yes.

On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote:
>> Isn't it what a scoped class is supposed to provide?
>>
>> class Rnd {}
>>
>> void foo() {
>>   scope rnd  = new Rnd; // reference semantic and stack allocated
>> }
>
> Does that actually work in D2? I thought it was a D1-only thing.

Yes, but for some unknown to me reason it was deprecated (or it will be in the future) in favour of std.typecons.scoped. Actually, it is used in many places throughout DDMD, so I don't think its going away soon.

On Monday, 15 August 2016 at 07:10:00 UTC, ZombineDev wrote:
> On Monday, 15 August 2016 at 04:56:07 UTC, Joseph Rushton Wakeling wrote:
>> On Sunday, 14 August 2016 at 10:11:25 UTC, Guillaume Chatelet wrote:
>>> Isn't it what a scoped class is supposed to provide?
>>>
>>> class Rnd {}
>>>
>>> void foo() {
>>>   scope rnd  = new Rnd; // reference semantic and stack allocated
>>> }
>>
>> Does that actually work in D2? I thought it was a D1-only thing.
>
> Yes, but for some unknown to me reason it was deprecated (or it will be in the future) in favour of std.typecons.scoped. Actually, it is used in many places throughout DDMD, so I don't think its going away soon.

When was it deprecated? I use it a lot and DMD 2.071.1 gives no warning.

bye,
lobo