Hmm - about manifest/enum

[Janice Caron]

On 1/2/08, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> "Walter Bright" wrote
> > Bill Baxter wrote:
> >> What was the fundamental problem with creating some syntax that would let
> >> you peel the reference part off a class reference?
> >
> > const(C)&[] a;
> >
> > is a sortable array of constant C's. But what is:
> >
> > const(int)&[] a;
>
> A sortable array of int references.

Now observe. Bill's idea of what & should mean is /different/ from
Stephen's idea of what & should mean. Here, Walter responds to Bill's
interpretation of what & should mean, and is immediately lambasted by
Stephen who interprets it differently.

This puts poor Walter in a hopeless position. I really have sympathy for him.

I have come to the conclusion that /no/ syntax for references and/or
tail constancy is devoid of its own insurmountable problems, but this
is just very, very hard to get across because everyone is using
different words for the same thing and/or the same word for different
things.

We could probably have simplified the discussion a bit by saying:
assume the syntax for mutable-ref-to-const data is "tailconst(T)",
rather than "const(T)&", and then we wouldn't have got sidetracked
into what "&" means in isolation.

But whatever the syntax, I must conclude that it can't be done,
without violating one or more of the principles of D, and that's what
Walter (and I) are trying to explain here.


> 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.  If you assign it to another int reference, then type
> now references the same thing as the new int reference.  If you assign it to
> another int, that is a compiler error (can't assign a non reference value to
> a reference just like you can't assign a non pointer value to a pointer).

D doesn't have a reference-to-int type, only reference-to-class-data.
This appears to be a new feature request.


> You may look at this whole post and think "ok, & is just like *, why even
> have &?", well, the point is, for classes, & is a reference to the class
> data, not a reference to a class reference.  So for a class C, C& x is
> equivalent to C x.  The thing & gets us is a way to specify universally
> 'reference to'.  This would actually be very beneficial to generic
> programming.

That leads to different problems. I know because that used to be my
idea, until I got persuaded I was wrong.


> const(*C)*[] array;
>
> This would be an array of mutable class references.

It doesn't matter what the syntax is. We can pick amonst syntaxes till
the cows come home. But whatever syntax you choose, you're still going
to have to answer the question "what happens when C isn't a class?"
(and cover all possible other types). And that's when problems start.


> One further thing.  If you could at least pledge to have a way to specify a
> tail-const class reference before 2.0 is officially released, I would be
> willing to accept that for now.

Walter cannot do that without sacrificing generic programming.