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, while final and const are adjectives. It's very awkward to use 'view':

view int * p = &x; // huh?

Andrei

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.

In any language with type constructor you are able to construct long, incomprehensible types. You don't need storage classes and qualifiers for that.


Andrei

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

I will notice that that process didn't start for the infamous magic variable "length". It's still in http://digitalmars.com/d/expression.html :o(.

Andrei

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.

Well, you see - quot capita, tot sententiae. :o) It's not about expectations as much as taking the good without the bad, while avoiding gratuitous incompatibilities. This is, I understand, high on Walter's priority list.

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

We know why C++ const is broken. The fact that it does not mean super const is not the reason.


Andrei

Derek Parnell wrote:
> 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.

Exactly. All I'm saying is that if you go through the steps of your system, you will see that it's unable to implement the notion of modular mutability.

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

We decided to use final to express symbol non-rebinding.

Andrei

Benji Smith wrote:
> 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.
[snip]

Me neither. Of course you don't want to do WSD to figure out the meaning of a keyword in a context. All I'm saying is that you can be expressive without blowing up your vocabulary by using collocations.

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

I think it's pretty clear to many in which places Perl went a little too far :o).

> 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.  At the end of the day, if we design a good feature, people (who participated here or not) will be glad to use it; if not, they won't. And that's that.

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


Andrei

Don Clugston wrote:
> 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.

Let me say it again: we know why it's broken. We will provide a fixed equivalent, not something entirely different. It's only natural to call the fixed equivalent the same.

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

Which are in the millions :o).


Andrei

Benji Smith wrote:
> 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.

You're "dead dead" right! :o)

Andrei

Reiner Pope wrote:
> 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?

Yes.

Andrei

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, while final and const are adjectives. It's very awkward to use 'view':
> 
> view int * p = &x; // huh?

yuh, fair point :(