shouting versus dotting

[Andrei Alexandrescu]

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