DIP1000: Scoped Pointers

[Joseph Rushton Wakeling via Digitalmars-d-announce]

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.