Remaining const niggles #1 - Custom POD types

[Janice Caron]

On 17/02/2008, Christopher Wright <dhasenan at gmail.com> wrote:
> >     T is a struct in which every member variable is pod
> >     T is a union in which every member variable is pod
>
> These two are more troublesome.

It's a /definition/. How can a /definition/ be troublesome. (Though
actually, it was incomplete. I complete it with the revised definition
below. I define a type T to be pod, if and only if one of the
following conditions apply:

    T is a primitive type
    T is a typedef for a pod
    T is a struct in which every member variable is pod
    T is a union in which every member variable is pod
    T is const(U), for some U, where U is pod
    T is invariant(U), for some U, where U is pod

My definition is unambiguous, and succeeds in defining every single
type as either pod or not-pod. This is in no way troublesome.


> You could define an opImplicitCast that
> unconsts the struct, though that might involve an additional copy (or it
> might not).

One cannot "unconst" something without an explicit cast. This is
precisely what I aim to avoid. The explicit cast should be
unnecessary, whether within opImplicitCast (or any other function), or
not.

Explicitly unconsting something with a cast is dangerous. It's
something I'd like to see avoided. (I could easily get my mystring
example to work, if I allowed myself explicit casts).

What you're suggesting is putting an /explicit/ cast inside an
op/implicit/Cast function. That just strikes me as scary.

More to the point, one should not need to do

    struct MyPODStruct
    {
        MyPODStruct opImplicitCast() const
        {
            return cast(MyPODStruct)(*this);
        }
    }

for every single pod struct you create. It is the const type system
which is at fault here - not the struct. It is the const type system
which needs to be addressed, and it should not be the struct writer's
job to find a workaround.