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.
