shouting versus dotting

[Andrei Alexandrescu]

KennyTM~ wrote:
> Michel Fortin wrote:
>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> I don't favor "." any more than the next guy, but I am glad there is 
>>> awareness of how unfit a choice "!" is. If you have any ideas, please 
>>> post them! Ah! I! Exclaimed! Again!
>>
>> Hum, I don't think we have much choice, it'll have to be something in 
>> this lot:
>>
>>     Positive!(real)(joke);
>>     Positive.(real)(joke);
>>     Positive#(real)(joke);
>>     Positive@(real)(joke);
>>     Positive&(real)(joke);
>>     Positive`(real)(joke);
>>     Positive´(real)(joke);
>>     Positive^(real)(joke);
>>     Positive¨(real)(joke);
>>     Positive\(real)(joke);
>>
>> Anything else I forgot?
>>
>> Or we could use special delimiter characters:
>>
>>     Positive<real>(joke);
>>     Positive“real”(joke);
>>     Positive«real»(joke);
>>     Positive#real@(joke);
>>
>> Each having its own problem though.
>>
>> My preference still goes to "!(".
>>
>> - - -
>>
>> The ".(" syntax makes me think more of something like this:
>>
>>     void func(T, alias methodOfT, A...)(T obj, A args)
>>     {
>>         obj.(methodOfT)(args);
>>     }
>>
>> which I which I could do. If methodOfT was a string, I suppose I could 
>> use string mixins, but it pushes diagnostics about misnamed methods 
>> further in the template and requires adding quotes to the template 
>> parameter when instanciating.
>>
> 
> Argh, actually I once have a strong desire making
> 
>   f«T»(x);
> 
> a valid construct, and to workaround that « and » can't be easily typed 
> you could substitute it with
> 
>   f\<T\>(x);
> 
> ---

Yah I would've like French quotes too.

> Anyway, I think the .() syntax is not as good as !() because the . is 
> pretty hideous before another punctuation mark (which may be a good 
> thing, I don't know), and one could easily miss it.
> 
> And even if .() is allowed, please don't remove !() -- it will break 
> significantly many code, and it doesn't cause any ambiguity either 
> (unlike .func() vs .prop).

Many languages have successfully dealt with similar situations by simply 
allowing both but promoting only one in books and other documentation. 
Speaking of which, I'm on verge of signing with Addison Wesley Longman 
for delivering TDPL in April.


Andrei