Hmm - about manifest/enum

[Bill Baxter]

Janice Caron wrote:
> On 1/1/08, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
>> What was the fundamental problem with creating some syntax that would
>> let you peel the reference part off a class reference?

Thanks for taking the time to write out the explanation below.

> It needs to be defined for all types, not just classes. If C is a
> class, and we define
> 
>     const(C)&
> 
> to mean mutable-reference-to-const-data, then you have only
> /partially/ defined &. You need to define it for all types. You need
> to define what
> 
>     const(T)&
> 
> means, for all possible types T. You need to define it for each of the cases:
> 
>     T is a primitive type
>     T is a pointer to U
>     T is an array of U
>     T is an associative array of U[V]
>     T is a struct
>     T is a union
>     T is a function
>     T is a delegate
>     T is a typedef
>     T is a named enum
> 
> Until it is fully defined, it is not possible to discuss its
> consequences. The fundamental problem is, things start to fall over
> when you start trying to define it for struct and union.

Seems easy enough.  Just make it mean no-op for the things where it 
doesn't make sense, namely things that aren't pointers.

struct Struct { int* p; int v; }
class Class { int* p; int v; }

const(int*)&     equiv to  const(int)*
const(int)&      equiv to  const(int)
const(Struct*)&  equiv to  const(Struct)*
const(Struct)&   equiv to  const(Struct)
const(Class)&    equiv to  const(Class)&

So this doesn't seem to be the point yet where "things start to fall 
over" that you speak of.

--bb