Extended Type Design.

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Benji Smith wrote:
>>>> I should also add that, in my opinion, any design where "const" 
>>>> means something other than "value resolved at compile time and 
>>>> immutable at runtime" would be a mistake.
>>>
>>> I hear you. I've always disliked C++'s mutable const.
>>>
>>> The most important thing at this stage is not the keyword, however, 
>>> but getting the design right. Andrei, myself and Bartosz have been to 
>>> hell and back several times over this over the last few months, and 
>>> have filled about two notebooks with scribblings. It's a difficult 
>>> problem.
>>
>> I very much agree.  But with little information about how these new 
>> flavors of const will work, it seems we're mostly stuck debating how 
>> they will look :-)  I'd welcome discussing the former issue, but I 
>> suspect that anything which is said here will have already been 
>> discussed between you three.
>>
>>> There are 3 distinct, and very different, flavors of constant:
>>>
>>> 1) rebinding of a value to a name
>>> 2) a read-only view of a data structure
>>> 3) a value that never changes
>>
>> It seems like #1 is only useful for reference types, which currently 
>> means pointers and class handles.
> 
> #1 is essential for expressing numeric constants.

Could you please provide an example?

>> Further, I don't think I've ever found a need for this particular 
>> class of immutability in C++.  How often does it really matter whether 
>> someone can reassign a pointer?
> 
> Very important. Often you want to bind a pointer to something and make 
> sure nothing can change that.

Perhaps this should be rewritten as "often one wants to..."  I just said 
that I have never felt a need for this :-)  Of the times where I've used 
this feature in C/C++, I think every single time has been simply out of 
diligence rather than because there was any risk of the pointer actually 
being reassigned.  A pertinent point to me is that D uses pass-by-value 
so the chance of a reference being silently reassigned "somewhere in the 
program" is typically almost nil.  About the only place where this is a 
real risk is with global variables, and since free functions support the 
property syntax, the programmer has a ready option to prevent such a 
reassignment from happening.  Besides, free globals are bad programming 
style anyway.

>> As for the other two, it seems like #3 is a storage class
> 
> No, because the value may embed pointers that you want to pass to 
> functions. Sorry for sounding dismissive, but we've been all of these 
> dead alleys for so long, it's all green codes: I can see the damn Matrix 
> now. Blonde, brunette, const, final...

That's fine.  You may have been down all these roads before, but I 
haven't.  I'm mostly asking to gain a better understanding of some of 
the background.

>> while #2 is an attribute on the variable itself.  So #3 implies #2.
> 
> No. #3 implies #2. If a value is super const, then it can be seen as 
> const. Essentially "const" loses a little of the precision that "super 
> const" has.

I'm confused.  I said "so #3 imples #2" and you replied "no, #3 implies 
#2."  What does the "no" signify?

>> I haven't given this much thought, but is it truly necessary to have 
>> two separate keywords for #2 and #3?
> 
> It's not! That's what I tried to do all along...

(see below)

>> Is this to aid the compiler in optimizing, or is there a perceived 
>> value here from a user perspective?
> 
> It will be absolutely essential for the well-definedness of 
> functional-style threads.

Okay, that's what I figured, though this seems to contradict what you 
said above.  So in essence, "super const" is actually necessary in some 
situations to indicate to the programmer that the data he is 
manipulating is truly immutable.  I almost feel like this feature should 
exist separately from the type mechanism, so there was a way to test for 
this instead.

>>  And is it necessary to distinguish all three by separate keywords?
> 
> It's not necessary :o).

So it sounds like it truly isn't necessary to separately distinguish #2 
and #3 via type qualifiers.  Is this correct?  I can appreciate the need 
for both, but I very much do not want all of this to become a confusing 
mess when applied to actual code.


Sean