On Sat, 05 Apr 2008 23:39:37 +0200, Jason House <jason.james.house@gmail.com> wrote:

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

Agreed. 'always' says what I feel this should be. Though if we want a shorter
word, what about 'ever'?

-- Simen

Simen Kjaeraas wrote:
> On Sat, 05 Apr 2008 23:39:37 +0200, Jason House <jason.james.house@gmail.com> wrote:
> 
>> 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.
> 
> Agreed. 'always' says what I feel this should be. Though if we want a shorter
> word, what about 'ever'?
> 
> -- Simen

Or perhaps something like mask a masked variable cannot be painted with any modifiers?

Jason House wrote:
> 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.
>>
>> I recently suggested to Steve that we use an adverb instead of an
>> adjective
> 
> What about always?  It's short and seems to work pretty well.
> 
> always invariant C x;
> always const C y;
> always C z;
> 
> My only concern is that stuff like "always int x = 5" could be confused as a
> constant.

All of those suggestions suck :P ... By those, I mean 'allways', 'frozen', 'permanently', Knud's suggestions , Paul's suggestions , etc.

Everything you are trying to describe is a *consequence* of the attribute you are trying to describe. (the consequence being that the type remains the same and is not affected by const/invariant of the owning class/struct)
But it is not really the nature of attribute. What *really* describes the attribute we want here?
'external'! As in:

  external invariant C x;
  external const C y;
  external C z;

The attribute readily describes that such member is not part of the logical state of the owning class/struct. (It may even be possible to reuse this for other things other than const/invariant.) I know that this issue is very subjective, but c'mon, doesn't it make much more sense than other suggestions?

(and yes, if we're anal about keywords, we could use 'extern' instead of 'external')


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D