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?

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


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

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?

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

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?

It's probably not terribly helpful, but 'view' is also a verb.


Sean

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++.
-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Fri, 16 Mar 2007 14:25:36 -0700, Andrei Alexandrescu (See Website For
Email) 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.
> 
> You're "dead dead" right! :o)

Reminds me a bit of the joke ...

Teacher: Two negatives imply a positive ... eg. 'not bad' is 'good'.
         But two positives never imply a negative.

Student: Yeah ... right, whatever.

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

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?


How about this? Using existing keywords, with a rename of "const":

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

Benji Smith wrote:
> Any overriding philosophy on the usage and
> overloading of symbol characters?

Not that I can think of.

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?

--benji

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.


[1] Well, technically they're not really readonly, it's more like non-writable (since the appropriate bit must be 1 on all levels of the paging data structures to get a writable page) but that's heading /even faster/ into the realm of nitpicking :).


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

Wouldn't it be better if 'const' just _meant what it said_ in the first place? :P

kris wrote:
> How about this? Using existing keywords, with a rename of "const":
> 
> 1) final       - rebinding of a value to a name
> 2) invariant   - a read-only view of a data structure
> 3) constant    - a value that never changes

Actually, that's pretty good too. Getting rid of the keyword "const" would definitely highlight that something is different between D's const-ness and the const-ness in other (anachronistic ;-) ) languages.

--benji