Hmm - about manifest/enum

[Steven Schveighoffer]

"Janice Caron" wrote
> On 1/2/08, Steven Schveighoffer 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.

Bill's idea in this statement above was congruent with my idea.  In Bill's 
statement above, he states that there should be some syntax that allows you 
to peel the reference part off a class reference, which is encompassed by my 
idea as well.  Bill's response to Walter's statement in a different thread 
is not in congruence with mine, but as this is a new syntax, we are both 
allowed to interpret what we think it should be.  There is no previous 
definition here, Bill and I are not on a side together arguing the same 
thing.

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

Walter is a big boy.  I'm sure he can figure out how to sort through all the 
subtle differences in feature requests made on this forum.

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

I do not wish to have tailconst structures or tailconst builtin types (such 
as int).  What I want are consistent tailconst references.  The fact that I 
can specify a tailconst reference (pointer) to a struct or int, but not a 
tailconst reference to a class is a big hole in my opinion.

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

Yes it is.  That was not a secret :)  Please view my post on 12/7 describing 
my original idea.

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

That anyone got persuaded that something is wrong is not proof that it is 
wrong.  "this leads to different problems" is not an explanation.

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

If C isn't a reference type, then it doesn't compile.

struct S {};
class C {};
alias S *X;
alias int *Y;

const(*X)*[] array; // compiles, X is a reference type
const(*Y)*[] array; // compiles, Y is a reference type.
const(*C)*[] array; // compiles, C is a reference type.
const(*S)*[] array; // failure, S is a value type, cannot be dereferenced.
const(*int)*[] array; // failure, int is a value type, cannot be 
dereferenced
const(*C)[] array; // failure, cannot declare a value type of *C.

Generic programming is already "broken" as you say because you can't treat a 
class as a value type.  There are differences which must be accounted for. 
For example:

class (T) C
{
   T x;
   this(int m)
   {
      // initialize T with m, assuming T is a class
      x = new T(m);
   }
}

What happens if T is a struct or int?  There is no generic way to do it.

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

Allowing *C syntax would not break anything that is not already broken.  If 
you have an example of why it would break generic programming, please share 
with us.

And I invite Walter to still respond to this personally.

-Steve