shouting versus dotting

[KennyTM~]

Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> "Ary Borenszweig" wrote
>>> Andrei Alexandrescu wrote:
>>>> Bill Baxter wrote:
>>>>> On Sun, Oct 5, 2008 at 1:06 PM, Andrei Alexandrescu
>>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>>> The problem I see with "!" as a template instantiation is not 
>>>>>> technical. I
>>>>>> write a fair amount of templated code and over years the "!" did 
>>>>>> not grow on
>>>>>> me at all. I was time and again consoled by Walter than one day 
>>>>>> that will
>>>>>> happen, but it never did. I also realized that Walter didn't see a 
>>>>>> problem
>>>>>> with it because he writes only little template code.
>>>>> I'm joining this discussion late, but I just wanted to say the !()
>>>>> doesn't bother me so much.
>>>>> What Walter said to you was pretty much how it went for me.  Seemed
>>>>> weird for a while, but I got used to it.
>>>>>
>>>>> I had to do several double-takes reading this thread thinking people
>>>>> were suggesting to use plain "()" because the little dot is just so
>>>>> easy to miss.
>>>>>
>>>>> I find !() to at least be easier on the eyes than greater-than
>>>>> less-than everywhere in C++.
>>>>>
>>>>> I wouldn't be adamantly opposed to a different syntax, but it would
>>>>> have to be better by leaps and bounds for me to think it was worth the
>>>>> headache.  And .() doesn't seem leaps and bounds better to me.
>>>>>
>>>>> I suggest, though, that if you think it looks a lot better you should
>>>>> at least post some example code showing "before" and "after" to try to
>>>>> convince us.  Seems like not many here see a lot of point in making
>>>>> the change, so rather than pleading with everyone to try it out on
>>>>> their own, why not just save us the effort and show us how it improves
>>>>> the code you're looking at?
>>>> Well part of the problem is that many people made up their mind just 
>>>> by imagining how it would look like, and it would be hard to sway them.
>>>>
>>>> Since you asked, here are some examples copied verbatim from a 
>>>> source file I found handy:
>>>>
>>>> alias DenseMatrix.(num) PulType;
>>>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>>>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>>>
>>>> For functions:
>>>>
>>>> sort.("a._0 == b._0 ? a._1 < b._1 : a._0 < b._0")(all);
>>>> result.id = std.conv.parse.(uint)(line);
>>>>
>>>> I was even more pleased while actually using The Sad Pirate than 
>>>> while imagining how it would be like, probably because typing is 
>>>> also easier (something that's not self-evident when just looking at 
>>>> the code).
>>>>
>>>> It looks like The Sad Pirate won't make it. People just don't see it 
>>>> as bringing enough improvement. But I think it is worth pursuing a 
>>>> number of alternatives. The two that to me are the most appealing are:
>>>>
>>>> a) Template{Args}
>>>>
>>>> Experience with Perl has shown that using {} as parens in addition 
>>>> to blocks is easy to pick up and easy on the eyes. Another argument 
>>>> in favor is that {} are "the right thing" - meaning they are parens 
>>>> that pair properly, as opposed to "<>". Also, they make today's 
>>>> "!()" look like a contraption that creates a new kind of parens from 
>>>> an existing (and ambiguous) kind of parens by prefixing it with a 
>>>> marker.
>>>>
>>>> b) Template at Arg and Template@(Args)
>>>>
>>>> This approach not only accepts the need for a contraption, it 
>>>> actually leverages it by allowing you to drop the parens if you only 
>>>> have one argument. That way "@" becomes a true operator, the 
>>>> template instantiation operator. Note that this can be done with the 
>>>> current "!" as well, except that Template!Arg does not look to me 
>>>> like anything enticing.
>>> So let's have them written down to be able to compare them easier:
>>>
>>> The sad pirate
>>> ----------------
>>>
>>> alias DenseMatrix.(num) PulType;
>>> alias SparseRowsMatrix.(num, HashSparseVector) PuuType;
>>> alias BiMap.(uint, Tuple.(uint, uint), BiMapOptions.lhDense) DicType;
>>>
>>> The curly braces
>>> ----------------
>>>
>>> alias DenseMatrix{num} PulType;
>>> alias SparseRowsMatrix{num, HashSparseVector} PuuType;
>>> alias BiMap{uint, Tuple{uint, uint}, BiMapOptions.lhDense} DicType;
>>>
>>> The at
>>> ----------------
>>>
>>> alias DenseMatrix at num PulType;
>>> alias SparseRowsMatrix@(num, HashSparseVector) PuuType;
>>> alias BiMap@(uint, Tuple@(uint, uint), BiMapOptions.lhDense) DicType;
>>>
>>> ---
>>>
>>> Personally, I find the {} easier to understand, and it's less typing, 
>>> but it doesn't allow to omit the closing } for one argument.
>>
>> I find the {} much easier to read than the . syntax.
> 
> To me too.
> 
>> The omitting of the braces is not a huge savings.  You are sacrificing 
>> a couple characters, actually only one if you are comparing @ with {}, 
>> at the expense of clarity.  I think it's a special case that is not 
>> really worth the trouble.  Besides, it's not hard to type {} when you 
>> are so used to it anyways, and if you are interested in saving 
>> characters, aliasing is a much better approach.
> 
> One thing I kinda dislike about Template at Arg is that adding a second arg 
> also asks for the parens. This is a problem present with single- vs. 
> multi-statement blocks as well:
> 
> if (a)
>     b;
> 
> If you want to add another statement, you need to add the curls as well:
> 
> if (a)
> {
>     b;
>     c;
> }
> 
> But then if you want to remove one of the statement you'd want to remove 
> the curls too to stay consistent:
> 
> if (a)
>     c;
> 
> This becomes tenuous enough that many people and some coding standards 
> actually prefer to use full block statements to start with, even when 
> they only contain one statement.
> 
>> One thing I should mention, since this is all about asthetics, my news 
>> reader keeps treating the name at param as a linked email address.  
>> Somthing that will be very annoying if we adopt the @ syntax and end 
>> up discussing templates on the NG.
> 
> Walter made another point, namely that "@" has "a lot of ink" in it. I 
> know what he means. I guess people who wanted templates to be 
> distinguished will find that an advantage :o).
> 
>> I still vote to keep ! as it's the easiest solution, and I never have 
>> found it annoying ;)
> 
> Well would you go on a strike if there was a little experimentation with 
> the curls?
> 
> 
> Andrei
> 

Frankly speaking one disadvantage of {} is that it is more difficult to 
refactor it (unlike .() where you just do a s/!\(/.(/g.)

If this is gonna effective, I suggest still keeping !() for a while, but 
make it deprecated, like what has been done to the === operator (the 
grace period from 0.72 (introduction of "is") to 0.126 (=== deprecated) 
to 0.174 (=== illegal)).