Benji Smith wrote:
> Bingo. It's like trying to describe something as "impossible impossible". If the first usage of the word didn't really convey impossibility, then you were using the wrong word to begin with.

Reminds me of the old assembler program:

	foo:
		MOV EAX, 3
		CALL BAR
		HALT		; stop the program
		HALT		; if skidding

Andrei Alexandrescu (See Website For Email) wrote:
>> But that's just me. Not everyone will agree with my opinion, and if I'm not in the consensus, I'll concede. But there seem to be a lot of people who agree with me.
> 
> I don't think so. This discussion is very small in numbers, and the strength of the interlocutors' arguments does not increase their number. 

What???? Blasphemy!!!!

>> I reiterate: "const" and "readonly" are the way to go. (Methods which promise not to modify the values of their parameters should use "readonly" rather than "const" in their method signatures.)
> 
> This makes const gratuitously incompatible to C++'s const, and (worse) also adds a keyword that's its equivalent. I don't think this can fly.

Good point. I like kris's suggestion to get rid of the "const" keyword entirely and replace it with something else ("constant" seems like a reasonable suggestion). Here are some other synonyms for "constant":

http://thesaurus.reference.com/browse/constant

There might be something useful in there. I'm personally fond of "chronic".

:-)

--benji

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

As for the other two, it seems like #3 is a storage class while #2 is an attribute on the variable itself.  So #3 implies #2.  I haven't given this much thought, but is it truly necessary to have two separate keywords for #2 and #3?  Is this to aid the compiler in optimizing, or is there a perceived value here from a user perspective?

Please don't get me wrong, I very much appreciate the desire for a comprehensive solution, but at the same time I wonder whether the struggle to integrate three fairly diverse concepts might be part of the reason why this all seems so complicated.  Are they all truly necessary?  And is it necessary to distinguish all three by separate keywords?

> C++ tries to do all three with one keyword, and makes a confusing hash of it.

Agreed, despite how the above likely sounds.


Sean

Derek Parnell wrote:
> On Fri, 16 Mar 2007 14:03:13 -0700, Andrei Alexandrescu (See Website For
> Email) wrote:
> 
>> Sean Kelly wrote:
>>> For what it's worth, I like: 'final', 'view', and 'const' the best. They're all short and meaningful, given the intent for each.
>> The problem with 'view' is that it's a noun, 
> 
> As in "to view or not to view, that is the question" <g>
> 
>> while final and const are adjectives. 
> 
> So how does the argument from NLP about 'super' being used to qualify nouns
> sound now? 

I must not see the connection. "super const int" is a suggestive collocation; "view int" is not.

>> It's very awkward to use 'view':
>> view int * p = &x; // huh?
> 
> But this isn't ... ?
> 
>   super const int * p = &x; 
> 
> How about ...
> 
>   const int * const p = &x;

That's final and expresses something entirely different.


Andrei

Derek Parnell wrote:
> On Fri, 16 Mar 2007 14:05:17 -0700, Andrei Alexandrescu (See Website For
> Email) wrote:
> 
>> Dan wrote:
>>> Wow...
>>>
>>> I've never put this much thought into const/final stuff.  Ultimately, the program *cannot* prevent data in memory from being changed.  It can at best prevent you from accidentally changing it; hence final and const declarations mean "I don't want anyone to change these, can you raise an error if someone tries to within D?"
>>>
>>> Also, the problem breaks down to 'what am I declaring const?'.  If I declare:
>>>
>>> const int* x; // is it the pointer, or the int?
>>>
>>> This doesn't seem important until you get to:
>>>
>>> const int[int**][]* x; // now what is it?
>>>
>>> Ultimately, you have this problem going through each and every pointer, array and value.  You could theoretically write this:
>>>
>>> const int[int**][]*[char[]][3][17][3,17]* x;  and now what are you going to do?  declare it:
>>>
>>> final const final final const const final final final final final const?
>>> Even final const! super const! final! const! doesn't work, in fact I agree it makes it worse.
>>>
>>> Good luck getting readability with that.
>>>
>>> Ultimately, something else needs to be developed.
>>>
>>> Perhaps a character we can use in alongside each item on the type declaration, or we need to be able to hit the whole line in one blow..
>>>
>>> Just my penny.
>> I'm not sure what this is meant to convey.
> 
> It is trying to convey the difficultly in determining which
> 'final'/'const'/'super const' instance refers to which part of the
> declaration.
> 
> Given ...
> 
>    int[int**][]*[char[]][3][17][3,17]* x;
> 
> and I want to make the 'x' immutable and the 'char[]' immutable, how does
> one write the declaration? Where does one place the 'final'/'const'/'super
> const' and where do the parenthesis go?

final int[int**][]*[const char[]][3][17][3,17]* x;

Andrei

Bruno Medeiros wrote:
> Benji Smith wrote:
>> Andrei Alexandrescu (See Website For Email) 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.
>>>
>>> Then how would you call "value that's not mutable through this alias" in a way that's not going to turn C++ immigrants away?
>>>
>>> Andrei
>>
>> I have no special love (nor contempt, of course) for C++ immigrants and don't really care whether D conforms to their expectations.
>>
>> I thought the point of D was to fix broken constructs from C++, and most C++ programmers I know consider its implementation of const (and especially how casting affects const) to be one of the prime offenders.
>>
>> --benji
> 
> Same opinion here. What makes D good is fixing broken constructs from C++.

Same opinion here too.

Andrei

Benji Smith wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>>> Really? I'd think super const would be used all the time. Anywhere a class has some invariant field, it'll probably be expressed as super const (if I'm understanding correctly that super const is the equivalent of #define constants in C++ or static final constants in Java).
>>
>> No. super const deals with pointers and transitivity. Final deals with non-rebindable symbols. I'd be hard pressed to think of many examples where class members are transitively immutable.
> 
> Aha. In that case, what would you think of the declaration:
> 
>   super const int MY_CONSTANT = 6;
> 
> Since a value type doesn't have any pointers, it wouldn't make any sense to apply super-constness to it, right? Should that be a compiler error?

This should be a compiler error.

Andrei

Benji Smith wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>>> But that's just me. Not everyone will agree with my opinion, and if I'm not in the consensus, I'll concede. But there seem to be a lot of people who agree with me.
>>
>> I don't think so. This discussion is very small in numbers, and the strength of the interlocutors' arguments does not increase their number. 
> 
> What???? Blasphemy!!!!
> 
>>> I reiterate: "const" and "readonly" are the way to go. (Methods which promise not to modify the values of their parameters should use "readonly" rather than "const" in their method signatures.)
>>
>> This makes const gratuitously incompatible to C++'s const, and (worse) also adds a keyword that's its equivalent. I don't think this can fly.
> 
> Good point. I like kris's suggestion to get rid of the "const" keyword entirely and replace it with something else ("constant" seems like a reasonable suggestion). Here are some other synonyms for "constant":
> 
> http://thesaurus.reference.com/browse/constant
> 
> There might be something useful in there. I'm personally fond of "chronic".
> 
> :-)

Believe me, I pored over thesauri for a long, long time.

Andrei

Frits van Bommel wrote:
> Walter Bright wrote:
>> Frits van Bommel wrote:
>>> Seriously though:
>>> "readonly" would mean that you (meaning any code that can access the symbol so declared) can only read data referenced through it, but someone else _may_ be able to write to it[2].
>>
>> My perception of that is different. I used to do embedded systems, and
>> 'readonly' means the data went into ROM. Also, marking a page in a virtual memory system as 'readonly' means that nobody can modify it.
> 
> Perhaps, but my perception of 'const' is different ;). Particularly, it seems to be short for "constant", which is therefore what it should mean. Not "*you* can't change this, but someone else might anyway".
> 
> Oh, and on x86 (and amd64) processors the operating system is allowed to write to 'readonly'[1] pages unless it sets the WP (Write-Protect) bit in system register CR0. Note: as this bit is *off* by default, it needs to be explicitly turned on by the OS.

So *that's* why Win32 doesn't complain when constant data is modified and pretty much every other OS does.  Good to know.

By the way... I feel the same about the meaning of 'const'.  On some level I still even think that const-by-default is the correct choice, but now that D has hit 1.0 that will be a much harder sell.


Sean

kris wrote:
> How about this? Using existing keywords, with a rename of "const":
> 
> 1) final       - rebinding of a value to a name
[moved '2)']
> 3) constant    - a value that never changes

These two are fine by me.

> 2) invariant   - a read-only view of a data structure

No. Just No.
For one thing, the data structure can vary :) : anyone with a mutable reference can change the value from under your nose, so "does not vary" simply isn't applicable here.
But more importantly, invariant has a very clear and defined meaning in computer science. It should not be overloaded like this.