Const Ideas

[Janice Caron]

On 12/1/07, Jesse Phillips <jessekphillips at gmail.com> wrote:
> Based off of what you said in my other post, Walter will not change D's
> transitivity, Craig's proposal violates this.

Hmm... Someone's misunderstood something. I totally agree with Walter
that transitive const is the right way to go.


> As a lot of the discussion
> here has suggested a solution for having a const ref with mutable data.

I don't think so. It's more about the distinction between const X and
const(X). What we're after is a syntax for mutable ref to const data
(not the other way round). What I'm saying is, if X is a class, then

    const X x; // fully const
    const(X) x; // fully const
    const(X)& x; // mutable ref to const data

There shall be /no/ way to specify const ref to mutable data.

Further, if X is not a class (say it's a struct or an int or something), then

    const(X)& x; // Errror - will not compile.



> So if I am correct then the real problem becomes with,
> const X x != const(X) x

Yes. I've been saying that for a long time now. const(X) must mean the
same thing as const X because otherwise it's just silly.



> const TYPE * foo  // *foo immutable, foo mutable
> const(TYPE) * foo // same as above
> const(TYPE *) foo // foo and *foo immutable, but foo can be rebound

I stress again the general principle that const X must mean the same
thing as const(X). Thus must be true regardless of the type of X. In
particular, it must be true when X == TYPE *, and hence "const TYPE *"
needs to mean the exact same thing as "const(TYPE *)".

The principles that "everything inside the brackets is const", and "if
the brackets are omitted, everything is const", cause no problems
/except/ for class references. Pointers are not a problem. Only for
class references do we need extra syntax, and it was for this purpose
that I proposed "const(X)&". (I wasn't the first person to suggest it
though).


> It would appear this meets at least most of the complaints const() does
> not have a special meaning, everything can be achieved with one const
> keyword, transitivity holds, no ambiguity, everything in const() is
> const.

const(X) must mean the same thing as const X, for all X. Unless you
have that, there will always be complaints.


> The only problem is that it would break all previous code,

D1 doesn't even /have/ const, so that's hardly true. The D2 branch is
experimental, and those of us using it are full expect things to
change. It's kind of the whole point of the branch.