Rvalue references - The resolution

[Zach the Mystic]

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?