Joel C. Salomon 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)
> 
> 
> How about “const const”?  No new keywords, no reuse of keywords in disparate contexts, and equally noticeable to the eye.
> 
> --Joel

The whole things about adding *more* constantness to const screams one thing very loudly: the applicability of the word "const", in this context, is borked :)

kris wrote:
> Joel C. Salomon 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)
>>
>>
>> How about “const const”?  No new keywords, no reuse of keywords in disparate contexts, and equally noticeable to the eye.
>>
>> --Joel
> 
> The whole things about adding *more* constantness to const screams one thing very loudly: the applicability of the word "const", in this context, is borked :)

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.

--b

On Fri, 16 Mar 2007 12:38:00 -0700, 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.

Thank you Benji ... I've been trying to write a response to that but everything I wrote came out as too abusive or obnoxious. You have nailed it though.

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

Walter Bright wrote:
> 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

I appreciate the thought you guys have put into it. And the implementation sounds exactly right, from a semantic perspective. It's just the syntax that's slightly wrong, to me.

Using your mapping above, I'd tweak it slightly to read:

1) final
2) readonly
3) const

On a side note: if the existing proposal was enacted, I think the exclamation point would be the most commonly overloaded symbol (possibly only competing with * for multiplication, pointer declaration, and pointer dereferencing), while other symbols (like ^ or %) are currently only single-purpose. Any overriding philosophy on the usage and overloading of symbol characters?

--benji

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.

'super const' at least has the connotation of being "constant, this time we mean it".

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


Glad to hear you guys are open to considerations. For purpose of discussion, you /could/ adopt the following instead:

1) final       - rebinding of a value to a name
2) view        - a read-only view of a data structure
3) constant    - a value that never changes

Not only is that pretty clear, it also dumps the "const" keyword that may otherwise cause some "adjustment" for C++ people

Andrei Alexandrescu (See Website For Email) Wrote:

> Bruno Medeiros wrote:
> > What is the status of the experimental designs for the "storage classes" manipulation that Andrei and others where thinking of for D. The last I heard from it was Andrei's max suggestion from his max design challenge, however, I think that suggestion may suffer from some problems in regards to the "maxtype" requirement, plus it is wholly incomplete in regards to how storage classes interact between each other. Like Andrei said, what is a "const inout lazy const char[]", if valid at all? Is there any news here? Is there a working(aka complete) design?
> 
> We have talked about a design. In short, the intent is to define three flavors of immutability:
> 
> a) final - a simple storage class controlling the immutability of the bits allocated for the symbol per se;
> 
> b) const - type qualifier meaning an immutable view of an otherwise modifiable data. const does not control the bits of the object, only the storage addressed indirectly by it (transitively);
> 
> c) "superconst" - denoted as "const!" or "super const": type qualifier meaning that the data is genuinely unmodifiable.
> 
> There is talk about deprecating lazy if it's best implemented via other mechanisms. There is also talk about deprecating "inout" in favor of "ref" on grounds that the often-useful "inout const" is likely to become #1 reason for bashing D.
> 
> To read a declaration like "const inout lazy const char[]", you can first parenthesize it appropriately:
> 
> const(inout(lazy(const(char[]))))
> 
> The lazy thing is really a delegate that returns a const char[]. The inout around it passes that delegate by reference, and the const at the top makes the delegate immutable.
> 
> 
> Andrei

So, would this allow you to express the associative array requirement, that the key must never be changed after it is set?

char[] myKey = "foo";
myAA[myKey] = "bar";
myKey = "something else"; // ERROR: this stuffs up the AA

would you write the getter's signature as superconst?

T set(super const K key) {...}

Is super const allowed as a parameter type?

On Fri, 16 Mar 2007 17:56:57 +0300, Dan <murpsoft@hotmail.com> wrote:

>
>> No, at first there must be 'D with macros' (like 'C with classes') and
>> only then -- D++ :))
>
> *shudder*

It was a joke.

> D already has templates.  it shouldn't have a separate macro language.  Having one indicates that the language itself somehow fails.  Templates *should* be sufficient.

My expirience in C++ and Ruby says that a language must have no macro system at all (like in Ruby) or must have a very powerful one (much more powerful than in C/C++, Nemerle is a fresh example). If D have started movement to support macros it must go as far as possible. I think.

> Using the ++ notation for the language is dangerous.  It allows you to only upgrade once.  You can't have a D, D++, D 2.0 etc, it just doesn't fit, 'causing the language to completely stagnate.  Then someone else has to come along and invent a language E.

E programming language already exists: http://www.erights.org/ ;)
And it grows from the other side of BCPL-C-C++ family -- from Java's branch. So the name of D can't be changed to E, only to D++ or D 2.0 :)

> The simpler the language is, the better.

Oberon was a very simple language, but where is it now?
C++ have never been simple. Java isn't a simple language now. Ruby isn't simple. And this language are very successful in real world. And D will be, I hope.

-- 
Regards,
Yauheni Akhotnikau

kris 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?
> 
> 
> there are explicit names for that sort of thing; "immutable", "readonly" , "view" etc.  Reading through the various replies gives the impression that you're concerned about propogating the broken C++ semantics than ensuring D corrects those faults ;)

No, just no gratuitous incompatibilities and misunderstanding. For example, "readonly" reminds some of ROM, which is really immutable. Then, "view" is too common a word to steal it as a keyword. Finally, "immutable" is again ambiguous.

> I think it's worthwhile ensuring D gets it right instead, and I'll happily change all of Tango to reflect that if necessary. Breaking source-code for a keyword that is currently used rarely is not a problem. Incorrect or dubious/confusing semantics are. It may be worthwhile dumping the "const" keyword altogether, to limit confusion.

You know, that might be a good idea.

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

Thanks, that's good to hear. Dropping inout would be one of the harder decisions to make.


Andrei

Joel C. Salomon 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)
> 
> How about “const const”?  No new keywords, no reuse of keywords in disparate contexts, and equally noticeable to the eye.

It was on the plate briefly. Probably it would be an uphill battle to convince people to enjoy it.

Andrei