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.
