> How about “const const”?  No new keywords, no reuse of keywords in disparate contexts, and equally noticeable to the eye.
> 
> --Joel

Noticeable alright!  I can't even type those characters.  : D

kris wrote:
> BTW, you've also mentioned changing "inout" to "ref" instead? That would probably break more code than a renaming of const; I know both Tango and Mango use inout quite a bit, but I'm happy to change those as necessary. Other people likely feel the same way.

Changing inout to ref would be a very long process in several stages:

1) Adding ref as a keyword and documenting its usage
2) Recommending changing usage from 'inout' to 'ref'
3) Removing 'inout' from the documentation
4) Producing a warning on 'inout' with -w switch
5) Deprecating 'inout'
6) Removing 'inout' as keyword

Also, 'inout' is easily greppable, and very likely is unique enough that using nothing more than a global search/replace will work.

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

Frits van Bommel wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Don Clugston wrote:
>>> My problem is, I don't see any connection between "don't touch" and "constant" except that C++ got them confused. In every other other context outside of C++,  "constant" means "it will not change".
>>>
>>> Mathematically, you can "hold something constant" (even though it is actually a variable), but as long as it is being held constant, it can't change.
>>>
>>> Suppose in a function, you have 'const' access to a global variable.
>>> Another thread with write-access to that variable can change it, while the function is executing.
>>>
>>> It makes sense for a function to have read-only access to a variable, and need to obtain a mutex when it wants to obtain the current value.
>>> But that's not a constant in any reasonable sense of the word.
>>
>> The difference between math and computer memory is that all too often in the latter case you want to express modular separation very often. Modular separation (in this context) means that the right to modify a certain object is owned by some part of program, and other parts may be offered only a view of that memory. This is such an important concept, even C adopted it. All of C's library functions that take pointers are anontated in their signature to specify whether or not they modify their input or not.
>>
>> You want to enforce modular mutability cheaply. If D's immutability features fail to achieve that, we've done nothing.
> 
> I don't think he's arguing against immutable views, just against calling it 'const' ;).

Exactly. Thank you. I'm purely concerned about the name.

On Fri, 16 Mar 2007 11:02:39 -0700, Andrei Alexandrescu (See Website For
Email) wrote:


> void print(const char[] message); // not modifying message
> 
> void main()
> {
>    char[] myMessage = readln();
>    print(myMessage); // error! myMessage is changeable!
> }
> 
> I truly think we've distilled the simplest language within our requirements.

Maybe the concepts but I'm not so sure about the usage.

Given a function signature that has an array argument, there are two independant things we might want to remain unchangeable - the reference and the data referred to.

To me, the signature ...

  void print(const char[] message)

looks like 'const' is qualifying 'char[]' because that's what it is next to, and the 'message' looks like it is not qualified. So the signature looks like it is saying, the data is 'const' but the reference is not.

Thus this below signature looks more like what you are trying to express ...

  void print(char[] const message)

And to make both unchangeable then this looks better to me ...

  void print(const char[] const message)

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Andrei Alexandrescu (See Website For Email) wrote:
> 
> Working in NLP myself, I totally disagree. Natural language is rife with homonimy and synonimy, and we're all very, very happy with that. But in this case we don't even have to go that far: "super" is an adjective meaning primarily "of high grade or quality" and qualifies a noun. If there's no noun, you don't know what is "of high grade or quality". It's a fact, and we don't even blink.
> 
> Andrei

I've also worked in NLP quite a bit, but I don't think the constructs of natural languages are necessarily healthy in artificial languages.

Many natural language constructs are only distinguishable through contextual analysis awareness or sense disambiguation (anaphora resolution and prepositional phrase attachment are among the most difficult to disambiguate).

Natural languages rife with ambiguity may be easy for native speakers to disambiguate (thanks to the semantic model we develop during early childhood), but those ambiguities make it more difficult for adults to learn new languages.

I like artificial languages to be artificial. I like them to be concise and unambiguous. I like them to have context-free grammars free from left-recursion. I don't like the word "static" to mean one thing in one context and something else entirely in another context. I don't like keywords to contain punctuation marks. And I don't like phrasal nouns (like "super const" or the inevitable "super duper const").

Just like highly ambiguous natural languages are difficult for adults to learn, I think synonymy and homonimy make it more difficult for professional developers to learn a new programming language.

I used to write a lot of perl code, and the constructs it borrowed from natural language (synonymy, homonimy, anaphora, implied words, pronouns, etc) are some of the things that drove me away from the language toward languages with more explicit semantics (java, C#, python, d).

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

--benji

On Fri, 16 Mar 2007 09:55:15 -0700, Benji Smith wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
>> We've shoved keywords like "readonly" and "view" for a while, and they just added more confusion than cleared, at a high cost. If (as I suspect) super const appears relatively infrequently, it might be fine to just encode it as the mildly verbose "super const". In fact, it's shorter than "keepyourgrubbyhandsoff". :o)
>> 
>> Andrei
> 
> 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).
> 
> Let me join the ranks of those who hate both versions of the new syntax.
>   const! looks either like a template or like "not const". You guys may
> think you're saving a keyword, and that might be technically correct
> from the perspective of the parser. But, for the perspective of the D
> developer, it still looks like you've introduced a new keyword, but it's
> a keyword that's A) nearly identical to another keyword, and B) contains
> a symbol. Ugh. I really. Really. Really. Hate it.
> 
> Using "super const" is also annoying because all of the other storage classes use a single keyword. Now we've got this weird case that uses two keywords. And the word "super" is now overloaded in two completely unrelated concepts.
> 
> (By the way, I don't like "static if" either. I think the right choice would have been #if, #foreach, etc. And I think C++ made a mistake by defining "long long" and "double double" types as well. Presumably, that saved some keywords, but we'd all have been better off if the types were defined as int8, int16, int32, int64, float32, float64, etc).
> 
> I vote for "readonly" and "const". Anything else seems like a mistake.
> 
> --benji

Well expressed. My think is almost 100% aligned with these thoughts above.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Andrei Alexandrescu (See Website For Email) wrote:
> Benji Smith wrote:
>> I vote for "readonly" and "const". Anything else seems like a mistake.
> 
> Which is which? How would you have people distinguish them without running to the manual? How would you explain C++ immigrants that const is actually readonly, and there is a const, but that const means something else than their const?

Hospitality to C++ immigrants is definitely important. But since C++ const is broken, there's inevitably going to be some culture shock.

I think we're OK as long as D const is more restrictive than C++ const
 -- so that writing C++ code in D will either work the same as in C++, or fail to compile.
And I don't think that the confusion exists for anyone other than C++ programmers.

Don

On Fri, 16 Mar 2007 11:48:47 -0700, kris wrote:

> ... but I'm happy to change those as necessary. Other people likely feel the same way.

I am more than happy to change my source code if the result is easier to read and an improved D.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

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.

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

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

For the purposes of discussion, and to avoid confusing ourselves, we adopted working names of:
1) final
2) const
3) super const

The hard part is to figure out how these 3 interact, how they look & feel, how they work with type deduction, type inference, type combining, how do we sidestep the clumsiness in C++'s handling of it, etc.

Once that's all done, picking the right keywords is a whole 'nother discussion, with several considerations:
1) common use of 'const' in C++, and the expectations and comfort people coming from C++ have with it
2) your point above, that const should be constant
3) keyword minimization
4) avoid stepping on commonly used names
5) ease and economy of typing