Extended Type Design.

[Kevin Bealer]

Andrei Alexandrescu (See Website For Email) wrote:
> sclytrack wrote:
>>> IMHO (b) should be 'readonly' and (c) should be 'const'.
>> [snip]
>>
>> vote++
>>
>>
>> Keywords
>> --------
>>
>> I also think keywords can be written attached to one another.
>> Like if you were to really call it "super const" have it called
>> superconst instead of super_const.
> 
> Yet you write static const not staticconst; public static not 
> publicstatic; static if and not staticif; and so on.
> 
> superconst came up too. But it creates a bad precedent. A healthier 
> precedent is to synthesize phrases, not new keywords, from the existing 
> keywords. Think of "static if" or "final switch". Very beautiful.
> 
>> It is like the foreach_reverse that we have in D. Why not
>> call it foreachreverse instead.
> 
> Probably it's best to call it foreach reverse. It's unambiguous, easy to 
> parse, does not add new keywords, and continues another nice precedent 
> set by extern(language) and by scope(exit).
> 
> 
> Andrei

How about the '1984' syntax?

double + const int; // very very const
double + super();   // call parent-of-parent constructor

(just kidding!)

I've read the description of the three const types and it's not clear to 
me which is which.  It seems like being "immutable per se" (final) and 
"genuinely unmodifiable" are pretty much synonymous.

This may seem backwards, but it would help me to keep them apart if I 
knew how they were implemented (semantically, not necessarily in terms 
of code generation).


As I understand it, "const" means "readonly view of something", similar 
to C++'s const but without the big "disable me" button.  The data is 
live but "under glass".

"final const" means the compiler never generates code to modify the 
underlying data and can assume (cache, do constant folding on) the 
underlying data.  Almost like a #define, except that you can take the 
address of it.

"invariant" is just like const, but refers to the symbol (and by 
extension the data) rather than just the data.


I'm guessing that volatile only affects const.  An invariant object 
doesn't need it and a 'final' is also essentially compile time foldable 
and thus might not even be loaded from memory per se.  (Eventually, and 
subject to quality of implementation, etc.)  But before/after a volatile 
block, a normal "const" might need to be refreshed from memory in case 
someone else had updated?


(Feel free to tell me that some of this has been answered, and I'll look 
over the thread again.)

Kevin