DIP1000: Scoped Pointers

Walter Bright via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Sat Aug 13 16:23:09 PDT 2016


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.



More information about the Digitalmars-d-announce mailing list