Multiple return values...

[Robert Jacques]

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.