On 04/04/2008, Janice Caron <caron800@googlemail.com> wrote:
> On 04/04/2008, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:
>
> >  Now to find a better name than paintable, and convincing Walter...
>
>
> Actually, all fields are paintable by default. It's the /un/paintable
>  ones that need a keyword. In C++, that keyword is "mutable", but
>  that's inappropriate for D.

My favorite keyword for this purpose is "exotic". Exotic fields exhibit strange behavior - you can't paint them with constancy; they should take no part in opEquals() or opCmp() or hash(). Strange indeed. And while "unpaintable" is very useful as a description, it is a little on the long side for an actual keyword.

That said, I'm with Stephen on this one. If we get the functionality, I won't be complaining about the keyword.

BCS Wrote:

> Steven Schveighoffer wrote:
> > 
> > I like the idea, but not the keyword.
> > 
> 
> every once in a while (about as often as I poke my head into one of these threads) I have the crazy idea that maybe we should just invent new words for the different flavors of const. words that have no connotations that people have to get around. My proposal for the five (?) different consts are:
> 
> a9ae7ba0-456b-4c61-82f0-93e19802f99f ff535086-ec2c-44bb-90ea-20eb8a46efc3 f025566c-8dff-4f41-b891-f37d19b470bb a8d70a83-022e-43d9-b3a5-c799b86e34eb a491956a-023e-4a60-8eeb-7cb37ef80b13
> 
> I'm not sure how well those will parse with the "-"'s <G>

Those all seem too much alike to me -- I'll probably use "f025566c-8dff-4f41-b891-f37d19b470bb" sometime by mistake when I reallly mean "a491956a-023e-4a60-8eeb-7cb37ef80b13".

I suggest "wall", "spear", "rope", "fan" and "snake"

I guess the day when we program in a natural language is still a ways off.

Paul

> Walter said that having mutable fields breaks the whole const system. He may have been right - but having /unpaintable/ fields is just fine and dandy. Everything works. const(...) and invariant(...) will paint only the paintable fields with constancy, but those fields the paint recursively.
> 
> It just works.

I like the idea. Here are some suggestion for a better name.
isolate
confine
detach
stable
steady
stationary
fixed
permanent

Simen Kjaeraas Wrote:
> 
> What reason would exist for having an unpaintable invariant field? As far as I've understood, invariant is implicitly castable to const, and casting away const/invariant is a Bad Thing, so whether it is const or invariant does little difference, except for functions that demand invariant arguments. In the latter case, the field is in a way 'less constant' when cast to const than for a normal instance, if I have understood things correctly (invariant values will not change, const values might change underneath you).


Wow. I should have read this thread earlier today.

I too don't see a reason for "unpaintable invariant". If you wrap a class in a const() or invariant(), the constness of its field should only be allowed to increase. c would have to remain invariant.

We could define unpaintable/mutable as fields that escape constness promotion. In this scheme, "unpaintable const" would be possible (not sure if it would be meaningful). Such field would remain const in invariant(C).

I feel that it would be a little bit complicated. I would stick to field being labeled:

unlabeled - follow constness promotion
const - at least const, might be promoted to invariant.
invariant - never less than invariant
unpaintable (mutable) - don't follow constness promotion


For my part i like mutable. I think it would have in D the exact same meaning it has in C++. But that's a war that would never end.

Knud Soerensen Wrote:

> 
> > Walter said that having mutable fields breaks the whole const system. He may have been right - but having /unpaintable/ fields is just fine and dandy. Everything works. const(...) and invariant(...) will paint only the paintable fields with constancy, but those fields the paint recursively.
> > 
> > It just works.
>

> I like the idea. Here are some suggestion for a better name.
> isolate
> confine
> detach
> stable
> steady
> stationary
> fixed
> permanent

untouchable?
impervious?
invulnerable?
unaffected?
erudite?
inflexible?
unyielding?
unreceptive?
obdurate?
adamant?
incorruptible?

It's hard to find a word that indicates "this is what I want, don't mess with it" without also evoking constancy.

intentional?
premeditated?
calculated?
purposeful?

How about our old standy "final"?

Paul

(sigh)  And so another Paint Shed Problem starts.

C'mon folks, everybody knows that the right syntax for this is actually:
	invariant(!const)

(removes tongue from cheek)

Most of the later terms seem confusable with non-changing data instead of type. I like the term isolate the best.

Knud Soerensen Wrote:

> 
> > Walter said that having mutable fields breaks the whole const system. He may have been right - but having /unpaintable/ fields is just fine and dandy. Everything works. const(...) and invariant(...) will paint only the paintable fields with constancy, but those fields the paint recursively.
> > 
> > It just works.
> 
> I like the idea. Here are some suggestion for a better name.
> isolate
> confine
> detach
> stable
> steady
> stationary
> fixed
> permanent

On 04/04/2008, Jason House <jason.james.house@gmail.com> wrote:
> Most of the later terms seem confusable with non-changing data instead of type. I like the term isolate the best.

Yeah, it's true - the thing that gets frozen is the /type/, not the /value/, so any word that is a synonym for const would be s-o-o-o-o confusing.

I recently suggested to Steve that we use an adverb instead of an adjective - e.g.

    permanently T x;
    permanently invariant(T) x;

However, neither of us really liked it that much. And then we decided we didn't care, coz what we care about is proving that the system works more than choosing a name for it. :-)

Janice Caron wrote:
> On 04/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>> Most of the later terms seem confusable with non-changing data instead of type. I like the term isolate the best.
> 
> Yeah, it's true - the thing that gets frozen is the /type/, not the /value/, so any word that is a synonym for const would be s-o-o-o-o confusing.
> 

What about "frozen" then.

On Fri, 04 Apr 2008 23:38:11 +0200, Russell Lewis <webmaster@villagersonline.com> wrote:

> (sigh)  And so another Paint Shed Problem starts.
>
> C'mon folks, everybody knows that the right syntax for this is actually:
> 	invariant(!const)
>
> (removes tongue from cheek)


Actually, seeing as it's the constancy of the variable that is const, we could use const(const) T x, const(invariant) T x, and const() T x. :p