Rvalue references - The resolution

[Michel Fortin]

On 2013-05-05 18:19:26 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 5/5/2013 4:43 AM, Michel Fortin wrote:
>> On 2013-05-04 18:33:10 +0000, Walter Bright <newshound2 at digitalmars.com> said:
>> 
>>> 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.
>> 
>> I just want to note that this has the effect of making any kind of heap
>> allocation not done by the GC unsafe. For instance, if you have a container
>> struct that allocates using malloc/realloc and that container gives access to
>> its elements by reference then you're screwed (it can't be detected).
>> 
>> The obvious answer is to not make @trusted the function returning a 
>> reference or
>> a slice to malloced memory. But I remember Andrei wanting to make standard
>> containers of this sort at one point, so I think it's important to note this
>> limitation.
> 
> I know Andrei has thought about this, but I don't know what the solution is.

Just rethrowing an idea that was already thrown here: support annotated 
lifetimes *in addition* to this runtime detection system. Those who use 
manual memory management will need it to make their code @safe. Those 
who stick to the GC won't have to. Anyway, you don't have to implement 
both right away, it can always be decided later.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/