Differentiate const flavors using CASE?

[janderson]

kris wrote:
> janderson wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Derek Parnell wrote:
>>>
>>>> On Thu, 22 Mar 2007 04:53:26 +0900, Bill Baxter wrote:
>>>>
>>>>> Here's a random thought:
>>>>> What about const vs CONST?
>>>>> The upcase version obviously being the more const of the two.
>>>>> The original proposal played with punctuation, and we've talked 
>>>>> plenty about spelling, but we haven't talked about playing with 
>>>>> case.  It would be an odd-ball among keywords, admittedly, but if 
>>>>> you asked 100 people which of 'const' and 'CONST' was the most 
>>>>> constant you'd probably get 100 votes for 'CONST'.  And he could 
>>>>> become good friends with foreach_reverse, the other odd-ball 
>>>>> keyword who is disparaged by the other kids because of his obesity 
>>>>> and the big staple in his belly button.
>>>>
>>>>
>>>> LOL ... Now that *is* funny.
>>>
>>>
>>> Yah :o). Speaking of foreach_reverse, probably it would be wise to 
>>> lobby Walter to deprecate it in favor of foreach(reverse) (item ; 
>>> collection) { ... }. The keyword(extra) syntax is definitely becoming 
>>> a D signature syntax.
>>>
>>>
>>> Andrei
>>
>>
>> //Using your other suggestion:
>> foreach(reverse) (item ; collection) (item2 ; x->GetColection(b)) 
>> (item3 ; collection3)
>> {
>>
>> }
>>
>> Its starting to get hard and harder to read IMO.
>>
>> Although perhaps the reverse could be come sort of iterator mechanism. 
>> You could define what order items are visited.  I mean, reverse would 
>> not be a keyword at all and would exist in some library.  Although I'm 
>> not sure how it would be implemented, and it may defeat the purpose of 
>> foreach_reverse being optimal.
>>
>> Just a thought.
> 
> shouldn't this perhaps be something like:
> 
> foreach (item; collection) (item2; x->GetColection(b))(item3; 
> collection3.reverse)
> {
> 
> }
> 
> 
> Now you can select a direction on the each container?
> 
> Naturally, this would avoid performing a copy of the content, and the 
> basic approach is quite easy to handle via a struct containing an 
> opApply(). It would open the door to alternate iteration approaches 
> also, such as skipping entries, merging, or whatever.
> 
> Tango does something vaguely like this for the text-iterators in 
> tango.text.Util

I agree.

Walter posted about this in another thread saying foreach_reverse was 
that way because of some performance nitch.  I still think that 
foreach_reverse is not the right way to do a reverse.  I think having it 
as a member or free function is the best.  The compiler should be able 
to detect .reverses on primitive arrays and optimize them.

Besides, how does the compiler currently optimize something written as 
an opApply?