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

On 12/29/12, Walter Bright <newshound2@digitalmars.com> wrote:
> Remember, a POD type can be enregistered

This means it can be passed in registers (for anyone not aware of the term).

On 12/28/2012 7:37 PM, Andrei Alexandrescu wrote:
> On 12/28/12 10:12 PM, Walter Bright wrote:
>> 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.
>
> The idea was to leave C++ compilers to change the order of fields in classes
> with private data for optimal layout. I don't know of any compilers that do, but
> that was the intent. PODs were not susceptible to such layout optimization
> because they had to be compatbile with C's layout.

I didn't know that, but it makes sense.

Interestingly, D's original design allowed fields in classes to be rearranged. This kind of fell by the wayside with the align directive.

On 12/28/2012 8:06 PM, Andrej Mitrovic wrote:
> On 12/29/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> Remember, a POD type can be enregistered
>
> This means it can be passed in registers (for anyone not aware of the term).
>

More than that, it means they can live entirely in registers.

12/29/2012 7:12 AM, 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.)"

I understand everything but constructors.
The question is how the following is different and should we make users jump through the hoops:

//non-POD?
struct A
{
int k;
  this(int v)
  {
   k = v;
  }
}

vs

//apparently POD?
struct A
{
 int k;
 static A opCall(int v)
 {
   A a;
   A.k = v;
   return a;
 }
}

Imagine that ctor-opCall are arbitrarily complex, but there is no postblit, opAssign and dtor.

P.S. I'm starting to hate the special nature of struct constructors: they can't have 0-arguments, now they disallow POD, what next?


-- 
Dmitry Olshansky

On 12/29/2012 1:03 AM, Dmitry Olshansky wrote:
> I understand everything but constructors.

I think David brought that up as well, there seems good cause to relax that.

On 2012-12-29 00:53, Andrej Mitrovic wrote:

> I suggest we implement a compiler trait via __traits(isPOD, Type).
> C++11 has is_pod, D should have a Phobos template that wraps around
> the new trait.

Do we need a new trait, can't this be done in pure D?

-- 
/Jacob Carlborg

On 12/29/12 4:03 AM, Dmitry Olshansky wrote:
> P.S. I'm starting to hate the special nature of struct constructors:
> they can't have 0-arguments, now they disallow POD, what next?

Yes, constructors should not influence the POD-ness of data; only postblits should.

Andrei

On 12/29/12 4:50 AM, Walter Bright wrote:
> On 12/29/2012 1:03 AM, Dmitry Olshansky wrote:
>> I understand everything but constructors.
>
> I think David brought that up as well, there seems good cause to relax
> that.

Great, thanks.

Andrei

On 12/29/12, Jacob Carlborg <doob@me.com> wrote:
> Do we need a new trait, can't this be done in pure D?

It can, but it's simpler to do in the compiler as it already has an
isPod() function.