struct_pod - what struct should have been

So, how about a new keyword 'struct_pod'?

This is equivalent to struct except that struct_pod explicitly requires
implementation as POD, except of course where this is impossible.

So, you can keep all the existing IMPLICIT rules that govern when a compiler
must implement structures as POD, but the use of struct_pod enables a
programmer to express this requirement explicitly - which consequently
enables them to define ANY operators for that struct, especially
constructors, assignment, and destructors. In other words, where a compiler
would otherwise have the discretional option to decide whether to implement
a struct as POD or not, struct_pod requires the choice of POD.

One could still have some limitations, e.g. that a struct_pod can't have
virtual functions, multiple inheritance, or references as members (though
one may be able to effectively oblige the compiler to implement refs as
pointers).

struct_pod Data // All operators permitted
{
    double r;
    Data(double rr):r(rr) { }
    Data& operator=(const Data& d) { r=d.r; return *this; }
 };

struct_pod M: Data, Z // Error - MI disallowed
{...
};

class M: Data, Z // Fine - non-pod can inherit from pod
{...
};

struct_pod R: Data
{ float& f; // Possible error - if we cannot require R.f to be
implemented as float*
    Data():f(...) { } // Constructor would be mandatory
};

class R: Data // Fine - implicit non-pod can inherit from pod
{ float& f;
    R():f(...) { } // Constructor is mandatory
};

struct_pod V: Data
{ virtual ~Data() { } // Error: struct_pod cannot have virtual
methods
};

class V: Data // Fine: non-pod can inherit from pod
{ virtual ~Data() { }
};

class X
{
    Data d; // Encapsulation fine
    virtual int M() const { }
};

struct_pod P: Data // Fine: explicit pod P can inherit from pod
{ int j;
};

class P: Data // implicit pod P is also pod
{ int j;
};

struct_pod S: X // Error: pod cannot inherit from non-pod
{
};

struct_pod Y // Fine, despite non-trivial constructor requirement
{
    Y() { ... }
    union
    { double m;
           Data d; // Explicit pod, so fine - despite assign-copy
operator
    };
};

class Q: Data // All members pod, so Q is pod
{ P p;
        Y y;
};

If you ask me, struct_pod is what struct should have been in the first
place, i.e. the layout and representation of data is important, but
functionality must not be consequently sacrificed in the name of safety.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]