On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Static Compiler Detection (in @safe mode):
1. Do not allow taking the address of a local variable, unless
doing a safe type 'paint' operation.
2. In some cases, such as nested, private, and template
functions, the source is always available so the compiler can
error on those. Because of the .di file problem, doing this
with auto return functions is problematic.
3. Issue error on return statements where the expression may
contain a ref to a local that is going out of scope, taking
into account the observations.
Runtime Detection
There are still a few cases that the compiler cannot statically
detect. For these a runtime check is inserted, which compares
the returned ref pointer to see if it lies within the stack
frame of the exiting function, and if it does, halts the
program. The cost will be a couple of CMP instructions and an
LEA. These checks would be omitted if the -noboundscheck
compiler switch was provided.
This is a brilliant solution. I'm glad my DIP seems to have
helped pivot the design process into this superior conclusion,
which uses something, i.e. runtime checking, I simply didn't
think of. I guess I didn't realize that the stack has "bounds",
so to say.
I suppose that underneath the hood the compiler will still track
the state of the return value using something like a 'scope' bit.
It's just that the user code doesn't need to see this bit, which
is probably how it should be. And it's great to realize that a
suitable safety framework - -noboundscheck - has been found which
already exists to encompass the checking.
I think the main data still to be researched is the slowdown with
both compile and run times with this checking implemented - not
that I see how to avoid it, but it's better to know than not to
know, right?
