escaping addresses of ref parameters - not

[Jason House]

Andrei Alexandrescu Wrote:

> Jason House wrote:
> > What constitutes escaping?
> 
> The callee tucks away the address of the ref parameter, or the address 
> of a direct field of it.

Ok, so this is head-escape analysis instead of transitive escape analysis.

Still, there are a few issues that I can see:
1. This may impose a significant restriction for reference types - any use of them as an "in" parameter will be a compiler error.  "in" does not imply no escape.  (Right now, I think pure functions can modify their arguments, so it's still possible for pure functions to allow escaping of in parameters into other function input arguments.)
2. It's not just the address of immediate members.  &a.b.c.d.e.f could also be an issue if b,c,d, and e are all value types.  (This is actually quite minor, it just needs a slight definition change of what escaping means)
3. How would you handle value type member functions that return ref variables?  They could be references to their internal member variables or a ref to something else.


> > If any other functions are called with
> > the parameter, even if they're const(T), it can still escape.  It may
> > be easiest to start with worrying about mutable references for now
> > and then extend to const references later.
> 
> const is orthogonal.

See issue #1 above.  "in" parameters can leak const references.  If you want to do this change and make const orthogonal, you need to change the default behavior of in parameters as well.