Bill Baxter wrote:
> This:
>   const int[int**][]*[char[]][3][17][3,17]* x;
> 
> is *already* unreadable (plus I don't think that [3,17] part is legal D).

---
$ cat test.d
import std.stdio;

void main() {
        int[3,17] x;
        writefln(typeid(typeof(x)));
}
$ dmd -run test.d
int[17]
---

http://www.digitalmars.com/d/expression.html#Expressions
---
The left operand of the , is evaluated, then the right operand is evaluated. The type of the expression is the type of the right operand, and the result is the result of the right operand.
---

This is mostly for C and C++ compatibility, AFAICT. There, it's typically used in macros that need it to perform multiple actions that can only be done in separate expressions, without having the macros expand to full statements.
But it's also used in one of the multiply-evaluated clauses of a loop statement (for example, it can be used to increment multiple counters of a for loop on each iteration).
It's also horribly abused as an overloaded operator in (amongst others) boost::lambda, where it replaces ';' for lambda expressions...

Andrei Alexandrescu (See Website For Email) wrote:
> Benji Smith wrote:

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

What about 'immutable' for 'really can't change'/'superconst', and const can stay as is?

--bb

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

And 'view' is also probably a very popular name for a variable thanks to things like the "Model-View-Controller" paradigm.

http://www.google.com/codesearch?q=view&hl=en&btnG=Search+Code


--bb

Bill Baxter wrote:
> 
> So you mean foreach(reverse) then?  I do like that!  You're right that it is quite D-like.  Too bad you weren't around back when foreach_reverse was introduced?   ;-)

This actually came up in more general terms:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D.announce&artnum=5015

Perhaps I over-complicated it with the talk of parallelism, but the idea was still there :-)


Sean

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> sclytrack wrote:
>>>> IMHO (b) should be 'readonly' and (c) should be 'const'.
>>> [snip]
>>>
>>> vote++
>>>
>>>
>>> Keywords
>>> --------
>>>
>>> I also think keywords can be written attached to one another.
>>> Like if you were to really call it "super const" have it called
>>> superconst instead of super_const.
>>
>> Yet you write static const not staticconst; public static not publicstatic; static if and not staticif; and so on.
>>
>> superconst came up too. But it creates a bad precedent. A healthier precedent is to synthesize phrases, not new keywords, from the existing keywords. Think of "static if" or "final switch". Very beautiful.
>>
>>> It is like the foreach_reverse that we have in D. Why not
>>> call it foreachreverse instead.
>>
>> Probably it's best to call it foreach reverse. It's unambiguous, easy to parse, does not add new keywords, and continues another nice precedent set by extern(language) and by scope(exit).
> 
> So you mean foreach(reverse) then?  I do like that!  You're right that it is quite D-like.  Too bad you weren't around back when foreach_reverse was introduced?   ;-)

Possibly even without the parens:

foreach (i ; array) { ... }

foreach reverse (i ; array) { ... }

I have a feeling Walter is unlikely to change that though :o).


Andrei

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Benji Smith wrote:
> 
>>> 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.
> 
> What about 'immutable' for 'really can't change'/'superconst', and const can stay as is?

I like it, and suggested it at a point. Walter said that it's bad marketing to define keywords in terms of a negative.

Andrei

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Deewiant wrote:
>> [snip]
>>
>>> In general, I do agree with your view, found elsewhere in the thread, that using
>>> existing keywords is best. That, or constructs like "scope (success)" where
>>> success isn't a keyword. I'm just currently a bit repelled by the pair "super
>>> const".
>>
>> Well how about "real const" then :oD.
>>
>> I think the good news is that you don't need to type it that often. You type:
>>
>> const char[] str = "Hi!";
>>
>> and the compiler figures out the "super" part itself.
> 
> Doh!  'real const'  of course... how could I leave that one out.
> 
> 
>   'real const'
>   'true const'
>   'double const'
>   'finally const'
>   'is const'
>   or
>   'is finally super double true real const'

'const is back and now its really mad' ?

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.

Why not just stop at '1'?   Inout is very descriptive if what you're planning to do is modify the input in a way that the caller can see the changes.  Just make it a synonym for 'ref'.  And instead of telling people not to use it, tell them to use it only when inout behavior is the actual intent.  Otherwise use 'const ref'.  And make 'const inout' be an error.

But in terms of the syntax tree generated, both 'inout' and 'ref' will be 'ref's.

--bb

Bill Baxter wrote:
> 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?
>>
>> Andrei
> 
> And 'view' is also probably a very popular name for a variable thanks to things like the "Model-View-Controller" paradigm.
> 
> http://www.google.com/codesearch?q=view&hl=en&btnG=Search+Code

However, viewonly is a possibility that's particularly expressive. As much as I'm wary of collapsed words, this is the contender I like the most. It's a bit long though, and given that it's also the most heavily used, it would lead to long lines.

But, as Walter put it very wisely: addressing immutability is a big problem, and syntax is only a fraction of it.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Benji Smith wrote:
>>
>>
>>>> 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.
>>
>>
>> What about 'immutable' for 'really can't change'/'superconst', and const can stay as is?
> 
> 
> I like it, and suggested it at a point. Walter said that it's bad marketing to define keywords in terms of a negative.

So, "invariant" is already a keyword ... what about that?

"Invariant" is currently used to stipulate a condition that must remain constant (or true) for the extent of the enclosing/relevant scope. Right now, it is used within a class only, but the semantics could presumably extend elsewhere too:

invariant int * p = &x;

void myFunc (invariant char[] arg) {}

in both these cases, the "invariance" should remain for the extent of the relevant scope?