POD

[Walter Bright]

On 12/28/2012 5:53 PM, David Nadlinger wrote:
> As far as I can see – and I'm merely guessing based on the isPOD comment here –
> the only reason for not just applying the C/C++ definition in the obvious way
> might be a quirk in the DMD backend implementation?

The idea with POD is not necessarily to be compatible with C++ POD, but to be 
compatible what the technical point of POD is. As I wrote on github,

"Remember, a POD type can be enregistered, if it also fits in registers and the 
code gen supports it. A non-POD can never be enregistered. A POD type can also 
be bit copied around at will without regard to needing to call any functions for 
any part of that. (This means POD can be spilled into registers, cached in 
registers, stored half in registers and half in memory, etc.)"

POD data must also exactly match the C version of it, otherwise, obviously, 
binary compatibility with C will be lost. D has no requirement to be binary 
compatible with C++ non-POD structs.

So, as long as we satisfy those requirements, we can invent our own definition 
of POD in a way that makes the most sense for D.

For example, C++ disallows mixed public/private data in a POD. I've never 
understood the reason for that restriction other than "C doesn't have private 
fields". D doesn't propagate that aspect.

Also, you made some good points about changing the D definition of POD. That is 
worthy of more discussion, and serves to underscore that we need an isPOD trait 
that is set by the compiler, not a reinvention in the library, because when 
isPOD changes then user code will automatically change in step.