unpaintable (the solution to logical const)

[Jason House]

Janice Caron wrote:

> On 05/04/2008, Jason House <jason.james.house at gmail.com> wrote:
>>  My only concern is that stuff like "always int x = 5" could be confused
>>  as a constant.
> 
> And let's not forget, the most common use is likely to be to make a
> mutable field, as in C++. Using a word that suggests const to make
> something permanently not-const is going to serious compromise the
> learning curve.
> 
> That's why I stuck with "unpaintable" for the description. It's a
> visual metaphor that's easy to picture. You can imagine mutable as
> white, invariant as grey, const as black, and operations like const(T)
> as going over T with a pot of black paint. Unpaintable fields are
> coated with varnish that paint won't stick to. It's not a bad
> metaphor, but, is "paint" the right verb for "change the constancy?" -
> I don't know.

I personally really dislike bolting on the whole painting description into
how D is explained just so that we can introduce a single keyword.

What I like about always is that it sort of implies its usage and could be
placed into documentation with little additional description.  Maybe I'm
strange, but "always C c" doesn't say immutable day to me.  It seems
sufficiently different and easy enough to remember.  It also has the very
nice feature of being short.

Other interesting alternative I thought of is "quarantine".  Walter might
like that it'd claim the title of the longest keyword in D :)  If this
stuff is impure and can't interact with pure code, it makes sense.

If long code for this funcitonality is ok, I've also wondered about some
kind of static if or version-like funcitonality that can explicity call out
what the type should be when the class is becomes const or invariant.
 

> I guess it's always indicative that an idea is generally liked, when
> people start arguing about what to call it, so that's great. What I
> would like to know, though, is this: Does anyone still think that this
> "breaks the const system"? Is there any reason to suppose that Steve
> and I missed something, and this will make the whole type system fall
> over?
> After all, Walter said, and here I quote word-for-word: "I 
> suspect that logical const is like perpetual motion - if you think
> you've solved it, you've just made a mistake somewhere". So that's the
> question for me: is there a mistake somewhere? I can't see one, but I
> was wrong before so that doesn't mean anything.

I don't think of this stuff as logical const.  Logical const allows const
functions to access mutable data.  As proposed, this does not allow that.

Of course, Walter has stayed out of this whole discussion, so we don't know
his thoughts.  I get the impression, however, that Walter won't get drawn
into design debates until he knows his opinion on it...  Meaning that he'll
either argue adamantly against something and then reverse his opinion in a
bombshell e-mail or stay quiet.  If only someone could find out what he and
Andrei are thinking about this.