Remaining const niggles #1 - Custom POD types

[Christopher Wright]

Janice Caron wrote:
> 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

I don't want to have to remember all that.

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

Yes you can:

struct Something {
    int member; //...
    Something opImplicitCast() const {
       Something s;
       s.member = this.member;
       return member;
    }
}

And if there's something you should do when changing from const to 
non-const, you can take care of that as well.

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

Whoever designed the struct can tell you whether it's safe to cast a 
const form of it to a mutable form.

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

So use it with caution. You're writing the struct, you should know 
whether it's safe.

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

You need to tell the compiler whether it's okay to copy a const struct 
into a mutable one. I don't have a problem with that, and you don't. You 
seem to come across the issue often enough that you want to vent about 
it, but you could write a template to do it easily enough.

I'm not writing the code that you are, so I don't see this issue often 
enough to consider it necessary to introduce a language feature to get 
const structs that you can implicitly cast to mutable ones. The only 
issue I see is that you can't currently overload opImplicitCast. 
However, that feature will be added at some point, probably sooner than 
any language feature you propose today.