Multiple return values...

[Timon Gehr]

On 03/12/2012 05:01 AM, Robert Jacques wrote:
> On Sun, 11 Mar 2012 21:49:52 -0500, Mantis <mail.mantis.88 at gmail.com>
> wrote:
>> 12.03.2012 4:00, Robert Jacques пишет:
>>> On Sun, 11 Mar 2012 18:15:31 -0500, Timon Gehr <timon.gehr at gmx.ch>
>>> wrote:
>>>
>>>> On 03/11/2012 11:58 PM, Robert Jacques wrote:
>>>>> Manu was arguing that MRV were somehow special and had mystical
>>>>> optimization potential. That's simply not true.
>>>>
>>>> Not exactly mystical, but it is certainly there.
>>>>
>>>> void main(){
>>>> auto a = foo(); // MRV/struct return
>>>> bar(&a.x); // defined in a different compilation unit
>>>> }
>>>>
>>>> struct return has to write out the whole struct on the stack because of
>>>> layout guarantees, probably making the optimized struct return calling
>>>> convention somewhat slower for this case. The same does not hold for
>>>> MRV.
>>>
>>> The layout of the struct only has to exist _when_ the address is
>>> taken. Before that, the compiler/language/optimizer is free to (and
>>> does) do whatever it want. Besides, in your example only the address
>>> of a field is taken, the compiler will optimize away all the other
>>> pieces a (dead variable elimination).
>>
>> That's the point of discussion. Fields of structure may not be optimized
>> away, because they are not independent variables. In D you have
>> unchecked pointer-to-pointer casts, and results of these casts should
>> depend on target architecture, not on optimizer implementation. At
>> particular, if such optimizations are allowed, some C API will no longer
>> be accessible from D.
>
> Unused fields of a structure are optimized away _today_. Unless a piece
> of code takes the address of the struct, all of the fields are treated
> as independent variables.

The only point I was trying to make is that the 'unless' part does not 
apply to MRV.