Rvalue references - The resolution

[deadalnix]

On Saturday, 4 May 2013 at 19:40:36 UTC, Tove wrote:
> On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
>> 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.
>
> Thanks for taking the time to detail the solution, I was quite 
> curious.
>
> Runtime Detection and opt-out with "-noboundscheck" is a stroke 
> of genius!
>
> "couple of CMP instructions"
> should be possible to reduce to only one with the "normal" 
> unsigned range check idiom, no?
>
> Looking forwards to hear more cool news. :)

It shouldn't be expensive. Additionally, consider that returning 
by reference is quite rare in practice.

Due to D semantic, returning by reference isn't a performance 
improvement (you get full performance returning by value in D), 
so you only return by reference when you intend to keep identity 
(ie, when you intend to modify a given value, in containers for 
instance).

I still think this is inferior to Rust's solution and like to see 
ref as a equivalent of the Rust burrowed pointer. It achieve the 
same safety at compile time instead at runtime, and incurs no 
extra complexity except in some very rare cases (when you have a 
function taking several arguments by ref and returning also by 
ref and the lifetime of the returned ref isn't the union of the 
lifetime of the ref parameters - a very specific case).

Talking with people at DConf, it seems that many of them didn't 
knew about how Rust solve that issue, and so I'm not sure if we 
should validate the proposal.

At a first glance, it seems that the proposal allow for rather 
painless later inclusion of the concept of burrowed pointer, and 
we can ensure that this is effectively the case, I'm definitively 
for it.

But we shouldn't close the door to that concept. After all, D is 
about doing as much as possible at compile time, and when we have 
the choice to trade a runtime check against a compile time one, 
we must go for it.