POD

[Dmitry Olshansky]

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