What can be done with copy constructors / post blits

[monarch_dodra]

On Friday, 1 March 2013 at 13:59:08 UTC, Johannes Pfau wrote:
> When trying to implement non-POD types for gdc some time ago I 
> asked on
> the dmd mailing list what the backend is actually supposed to 
> do for
> non-POD types. Walter answered that they should never be passed 
> in
> registers:
>
> --------------------------
>> Wouldn't it be legal to still pass non-PODs in registers when 
>> calling
>> functions and only copying them back to the stack if the 
>> address is
>> needed? As we pass structs by value anyway, how could this be
>> problematic?
>>
>
> No, not allowed. Consider why there are copy constructors, and 
> what
> they do.
> --------------------------
>
> Now that's probably because of my weak C++ background, but what 
> can you
> do with copy constructors that would break if the compiler 
> passed the
> non-POD type in a register to a function?
>
> Note: If I interpret this assembly properly dmd does do exactly 
> what
> I proposed and what's illegal according to Walter:
>
> D:   https://gist.github.com/jpf91/5064703
> ASM: https://gist.github.com/jpf91/5064764

Unsure what "pass in register" means. As in storing the data 
before calling the function in a register, as opposed to the 
stack?

In C++, if you ever copy or move anything, then a CC must be 
called. Because of this, I'd say you can't place a non POD in a 
register, because that would imply CC'ing the thing just to place 
it in said register.

In D, it is a little different, because you are allowed to move 
stuff in-memory without ever calling the CC. This is "D move 
semantics", and it works because D bans internal pointers. 
Because of this, I'd say you can pass by register.

Maybe Walter gave you his "reflex" C++ reply, and didn't realize 
that D relaxed semantics changed the rules?