Differentiate const flavors using CASE?

[Chris Nicholson-Sauls]

kris wrote:
> Chris Nicholson-Sauls wrote:
>>
>>
>> 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)
>>> {
>>>
>>> }
>>>
>>
>> Or better still, if we wanted to keep 'reverse' away from the collection:
>>
>> foreach (item; collection) (item2; x->GetColection(b)) (item3; 
>> collection3; reverse) {
>> }
>>
>> I wouldn't be above a 'foreach(i,x ; source ; order)' syntax in 
>> general, really.
>>
>> -- Chris Nicholson-Sauls
> 
> Except for one thing, Chris; basing the syntax on 'keywords' limits one 
> to what the compiler chooses to support? Basing the opApply() selection 
> on a method/property name instead (with optional arguments also) leaves 
> the door wide open for any implementation you can imagine?

I was actually thinking the third "parameter" should be one of: function, function 
pointer, delegate, variable containing referance to a delegate; rather than some 
language-defined set of order keywords.

int reverse   (T,U) (int delegate(U,T) dg) {}
int scattered (T,U) (int delegate(U,T) dg) {}

foreach (i,x ; some_array ; reverse  ) {}
foreach (i,x ; some_array ; scattered) {}

It would seperate ordering algorithms from the collections themselves, and also not 
prevent that approach so long as the current allowance for delegates and usage of opApply 
were retained (as, presumably, they would be).  Just a crazy idea.

-- Chris Nicholson-Sauls