Hmm - about manifest/enum

[Janice Caron]

On 1/2/08, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
> 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)&

OK, at this point, arguments start to happen, because not everyone
will agree on those definitions. For example, further down this
thread, Stephen Schveighoffer argues that "If references are to be
consistent, the meaning of an int reference is that it acts like an
int until you assign to another int reference". Instantly, much
confusion abounds because now people are arguing about what int&
should mean, instead of what actually happens when you nail down a
definition. But to avoid confusion here, we'll go with /your/
definition...


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

Using your definitions, the compiler is unable to tell whether or not
the following is OK:

    void f(T)(const(T)&[] a)
    {
        a[0] = a[1];
    }

This violates the D compiler rule of "context free grammar".

Of course you could define & differently, so that that particular
problem does not arise - for example by inventing generic C++-like
references to all types (which I believe is what Stephen suggests),
but you will find then that /different/ problems arise.