Remaining const niggles #1 - Custom POD types

[Christopher Wright]

Janice Caron wrote:
> On the whole, I'm very happy with the new const system. However, there
> are one or two niggles which remain, and I feel that enough time has
> passed that it's safe to start bringing them up for discussion. So
> here's my number one complaint. This works:
> 
>     string s = "hello";
>     char c = s[0];
> 
> Nothing unusual there, you might say. The problem is that the
> following /doesn't/ work (as in, won't compile!)
> 
>     typedef char mychar;
>     alias invariant(mychar)[] mystring;
> 
>     mystring s = cast(mystring)"hello";
>     mychar c = s[0];
> 
> The final line won't compile. The compiler, apparently, cannot
> implicitly convert an invariant(mychar) to a mychar. But why not? It
> can do that for char, and mychar is just a typedef for char. Changing
> mychar from a typedef to a struct wrapper doesn't fix things either.
> 
> But I believe there is a solution.
> 
> The fix is, the compiler must allow const(T) and invariant(T) both to
> implicitly cast to T, if and only if T is "pod". (Plain Old Data).
> This is a very simple thing to define. A type T is pod if and only if
> one of the following is true:
> 
>     T is a primitive type
>     T is a typedef for a pod

These two are fine. A typedef should work like the original type. I'm 
curious as to how typedefs and automatically casting from 
invariant(char) to char are handled.

>     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. You could define an opImplicitCast that 
unconsts the struct, though that might involve an additional copy (or it 
might not).