Hmm - about manifest/enum

[Janice Caron]

On 12/31/07, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> > ...and that would work now.
>
> Fair enough, but the solution still fails because I have to use double the
> space and extra processing, and creating such an array is too complicated.

Too complicated?

    const(C)*[] addPointers(const(C)[] a)
    {
        const(C)*[] r;
        foreach(i,e:a) { r ~= a.ptr + i; }
        return r;
    }

    const(C)[] removePointers(const(C)*[] a)
    {
        const(C)[] r;
        foreach(p:a) { r ~= *p; }
        return r;
    }

It's a few extra lines of code, that's all. I'm not saying this is a
generic solution which will solve every problem you can think of, but
the point is, there are always workarounds.

On the other hand, adding a tailconst function to D would wreck the
type system.

I wouldn't want a const(int)[] array to be mutable, and likewise I
wouldn't want a const(C)[] array to be mutable. Once upon a time I
argued for the syntax "const(C)&[]", but Walter patiently explained
why that would cause insurmountable problems elsewhere. So it's one of
those "lesser of two evils" things. Make the programmer think a bit
and do things differently, versus wreck the type system. I think
Walter made the right choice.


> D references ARE pointers.

So are C++ references.


> The problem is that with classes, I can't change
> the constness of the class without changing the constness of the pointer
> (reference).  With C++ I can.

No you can't. In C++, the equivalent declaration would be either of

    const C & * myarray;
    C const & * myarray;

That's a pointer to (=array of) reference to class C. Again, I'm not
even sure how you would initialise such a beast, but I'm certain you
wouldn't be able to change the target of a reference.

What /you/ want to do is (in C++) either of:

    const C * myarray;
    C const * myarray;

Well, if you remove the ampersand, then what you've done is you've
removed the reference semantics. In D terms, you've made C a struct,
not a class. The D equivalent then becomes

    const(C)*[] myarray;

(where C is a struct, not a class).


> It's not
> required for Walter's const dream to have class references always have the
> same constness as the referenced class itself.

It is. I know that's not immediately obvious, but if you follow
through all the arguments (which I don't want to repeat coz they're
long and complicated) you eventually have to conclude it can't be
done.


> The right answer is: tail-const for references and pointers, no
> tail-const for structs. <snip> I'm done arguing this point.

That's not logical. You can't say "The right answer is" and then
declare it end of subject. The logical thing to do is to work through
all the consequences until you reach a conclusion, /or/ to say "I
don't know what the right answer is and I'm done arguing the point".
Only Douglas Adams gets to say what the right answer is (42) without
having to explain it.


> If you can't see the value in having tail-const for class references
> after all this, and the lack of a good reason for not having it, then
> there is no reason to keep trying to convince you.

Not too long ago I was arguing exactly as you argue now. I didn't need
"convincing" because I already fully supported the idea, and argued
vociferously for it. However, because I remained open minded, I
engaged in argument, and Walter was able to persuade me I was wrong. I
have to go where the evidence leads.

I can indeed "see the value" in having tail-const for class
references. But now, I can also see the cost, and the cost outweighs
the value.