Bill Baxter wrote:
> 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.

That's very awkward. Exact synonyms fare real bad in all languages I know. It's chaff without any nutritional benefit. Everybody would have preferred that "=>" in Perl is something different from ",", or that template<typename T> and template<class T> would be different things in C++.


Andrei

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

How about taking Andrei's observation about extern(C) and scope(exit) and letting const have a modifier?

1) final
2) const
3) const(strong)

or something like that?  I guess the problem is that const(something) already has a meaning if it's something like const(int*).

--bb

kris wrote:
> 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?

I completely missed that one. I think it's a good idea to look into it as a candidate for a qualifier name. Thank you.

Andrei

Walter Bright wrote:
> Derek Parnell wrote:
>> 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?
> 
> final int[int**][]*[ const(char[]) ][3][17][3,17]* x;

Hmm... I think either one of you (Walter and Andrei) got bitten by the
"you have to put parens around the type or it'll get final'ed, too"
thing, or one of you got bitten by the "is this going to make it final?
 Jeeze, I dunno; better put parens in just in case."

This makes me somewhat worried :P

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Andrei Alexandrescu (See Website For Email) wrote:
> 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

Except then 'reverse' would have to be a keyword too, no?
Or would you do away with parens in the extern and scope cases too?  I liked the suggestion because it makes foreach and its reverse variant less of a special case.  scope and extern can be followed by things that that are keyword-like but that specify a specific variation of the keyword.  Likewise, foreach would be the same.  But if you're going to special case foreach in the end anyway, I see little point.  It would also open the door for some sort of foreach(parallel) construct without having to introduce yet another underscored keyword with double-digit character count.

--bb

Andrei Alexandrescu (See Website For Email) wrote:
> Derek Parnell wrote:
>> But you are saying that if I don't want 'final', I not
>> only have to avoid using 'final', I also have to put some of the phrase
>> (and I know I'll never remember which parts) in parenthesis. But wait ...
>> there's more. If I do want it to be 'final' all I have to do is not
>> use the
>> 'final' keyword.  Am I getting this right?
>>
>> Is it not possible to make reading code simple?
> 
> An intuition that I see reasonable is that const by default engulfs everything to its right:
> 
> const char[] str = "Hi!"; // same as const(char[] str) = "Hi!";
> 
> When it engulfs the symbol, it makes it immutable, hence final. So by putting the parens you limit const's power.
> 
> But I'd be glad to drop this exception. I'm not sure what Walter and
> people who'll have to modify their code would say though.
> ...
> Andrei

$ dmd -v1

With the v1 switch, I don't need to rewrite my code if it's already working and isn't being updated.  And even if for some reason I do need to rewrite my code, I'm more than happy to do it in this case, if it gets us a sane, exception-free const system :)

Heck, with D being as easy to parse as it is, I imagine that it wouldn't be terribly difficult for someone to write a source migration program; IIRC, Python actually had one of these for a particular version that broke several programs.

Yeah, it's going to catch some people, but D !is Cpp, and there will
always be things that are different.  So long as these breaking changes
are for the better, I can't imagine any reasonable person would complain[1].

	-- Daniel

[1]: Well, OK, they might complain anyway.  But it's like how I could complain that my plans of doing car maintenance-related stuff has been ruined by this blasted wet weather!

Considering that, as a country, we really need this sort of wet weather more often, and I know it, it's kinda an empty complaint :P

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Sean Kelly wrote:
> 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 :-)

You have it using foreach!(arg) syntax there.  But it's not really a template.  Maybe it could be, and if it were then that would be great syntax for it.  But otherwise it's just unprecendented.  A new special case.

But what Andrei points out is that there are two precedents for the keyword(subkeyword) syntax, where the possible subkeywords are pre-defined by the compiler and completely change the behavior of the keyword, or rather select very different behaviors all under the same general umbrella.  It's exactly what was needed for foreach and foreach_reverse.

--bb

Daniel Keep wrote:
> 
> Walter Bright wrote:
>> Derek Parnell wrote:
>>> 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?
>> final int[int**][]*[ const(char[]) ][3][17][3,17]* x;
> 
> Hmm... I think either one of you (Walter and Andrei) got bitten by the
> "you have to put parens around the type or it'll get final'ed, too"
> thing, or one of you got bitten by the "is this going to make it final?
>  Jeeze, I dunno; better put parens in just in case."

No, in this context the parens would be simply optional. Only when const occurs at top level it will engulf the symbol too.

Andrei

Daniel Keep wrote:
> 
> $ dmd -v1
> 
> With the v1 switch, I don't need to rewrite my code if it's already
> working and isn't being updated.  And even if for some reason I do need
> to rewrite my code, I'm more than happy to do it in this case, if it
> gets us a sane, exception-free const system :)
> 
> Heck, with D being as easy to parse as it is, I imagine that it wouldn't
> be terribly difficult for someone to write a source migration program;
> IIRC, Python actually had one of these for a particular version that
> broke several programs.

The python Numpy project has that too.  There have been a lot of changes from the old version of numpy called Numeric, but you can fix almost all of the common cases using a script that comes with Numpy.

I suspect the script to upgrade D code would be much much MUCH simpler than that.

> 
> Yeah, it's going to catch some people, but D !is Cpp, and there will
> always be things that are different.  So long as these breaking changes
> are for the better, I can't imagine any reasonable person would complain[1].

> [1]: Well, OK, they might complain anyway.  But it's like how I could
> complain that my plans of doing car maintenance-related stuff has been
> ruined by this blasted wet weather!
> 
> Considering that, as a country, we really need this sort of wet weather
> more often, and I know it, it's kinda an empty complaint :P

Great analogy.

--bb

Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
[snip]
>> 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?
> 
> 
> I completely missed that one. I think it's a good idea to look into it as a candidate for a qualifier name. Thank you.

yw

If it gets tossed for whatever reason, It might be worthwhile renaming the current "invariant" to whatever is settled upon? That may reclaim a keyword at least.