Extended Type Design.

[Chris Nicholson-Sauls]

Kevin Bealer wrote:
> 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
> 

Disclaimer: My current best understanding.

Final -> You may not re-bind/re-assign to this symbol.  The data bound to this symbol (ie, 
the object, struct, array, etc) is fully mutable.  Its a storage class of the variable, 
and has no effect on the data itself.  Foldable if its value is a basic scalar, such as an 
int.

Const -> Part of the type, provides a read-only view into data owned by code elsewhere 
with a mutable referance.

Invariant -> Part of the type, guaranteed absolutely not to change.  Essentially a 
contract of sorts.. in fact, I'm starting to think of it as an invariant{} contract block 
which "simply" asserts the data is always in the same state as immediately after construction.


Side effects of combinations:

'final const' -> An unbindable read-only view.  Could be useful for passing read-only 
views of data by referance, ie: void foo (final const ref bar) -- foo cannot modify the 
data referanced by bar, nor can it reassign bar, which would've reassigned the original 
variable since its by ref.  (The data referanced is constant, the referance itself -- ie 
the symbol -- is not.)

'final invariant' -> Ultimate const'ness.  An unbindable variable whose value is a 
referance to unchanging data.

Man I can't wait for all this to finally ship, in the hopes that it will come along with a 
thorough user manual...

-- Chris Nicholson-Sauls