POD

[David Nadlinger]

On Saturday, 29 December 2012 at 03:13:00 UTC, Walter Bright 
wrote:
> 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.

I didn't doubt that we can invent our own definition, just that 
it is a good idea. ;)


> 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.

Yes, I don't understand that one as well – hm, maybe in order to 
allow the compiler to optimize the layout?


> 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.

Agreed – but I'm not quite sure if "plain old data" is defined 
(or, for that matter, used) in the language right now. Just about 
the only explanation given in the spec is in the glossary, which 
has »Refers to a struct that contains no hidden members, does not 
have virtual functions, does not inherit, has no destructor, and 
can be initialized and copied via simple bit copies.« (no mention 
of constructors) but then goes on to say »D structs are POD«, 
which is probably a remnant from D1 days.


David