Template instantiation syntax

[Dave]

"KennyTM~" <kennytm at gmail.com> wrote in message 
news:gcqnqd$161r$1 at digitalmars.com...
> Dave wrote:
>>
>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
>> news:gcogl4$28ui$1 at digitalmars.com...
>>> We seem to have reached a dead end on finding a significantly better 
>>> alternative than foo!(bar).
>>>
>>> All is not lost, though. Andrei is working on an emacs module that will 
>>> parse D code and replace foo!(bar) with foo«bar» for display only when 
>>> the editor is in D mode, the underlying text will still be foo!(bar). 
>>> (This doesn't affect D at all, only its display in Emacs.)
>>>
>>> Also, we're going to try using ! for single argument syntax, as in:
>>>
>>> foo!bar  is same as   foo!(bar)
>>> foo!10   is same as   foo!(10)
>>>
>>> etc. 0 arguments or more than 1 argument or arguments that are more than 
>>> one token long will still require !( ). We'll see how that works. I 
>>> think it looks rather nice.
>>
>> I don't like it because it is not consistent and therefore could make 
>> things ugly and even harder to comprehend where clarity is needed most --  
>> in a file full of mixed length template instantiations. It reeks of total 
>> hack to me, and I think this is opening a huge can of worms regarding the 
>> a!b!c issue. Inconsistency and things that smack of potential "corner 
>> case" are never good.
>>
>
> You can always use !(...); the current proposal is backward-compat.
>

But the problem I have with it is some poor sucker maintaining someone 
else's code who uses the new syntax, maybe even inconsistently in the same 
module.

> I wonder why no one complains “3 - 4 - 5” brings a huge can of worm. The 
> problem of ! as I see is that it is not associative (a!(b!c) != (a!b)!c), 
> so we can just define an associativity preference just like the - 
> (left-assoc) and = (right-assoc) operators.
>

Good point, except that would mean yet more rules to remember when the 
current !() syntax makes it clear. This whole thing will just make D 
templates harder to learn, understand, use and maintain.

>> I hadn't seen this mentioned lately; C#, Java and now C++0x are able to 
>> work around the '> >' issue and allow '>>'.
>>
>> a) It works for C++0x so it can be made to work for D using the same 
>> rules. I also assume that C# and Java compilers use the same methods as 
>> C++0x to work around the ambiguities with the right-shift operator.
>
> The argument against T<x> from the start is that it is more difficult to 
> parse. It is not impossible, it is just difficult. You can blame Walter 
> for being lazy.
>

Lazy doesn't mean to Walter what it means to the rest of us... To Walter, 
"lazy" is another way of saying for "I don't agree and I'd rather just do 
something else" <g>

I just saw a post where Walter says he hates the angle brackets and that 
syntax matters. I agree that syntax does matter, and apparently many 
developers and other language designers don't have a problem with the "<>" 
syntax. So maybe Walter needs to bite the bullet and D should just use it. 
Maybe D is bucking a trend here where it shouldn't.

>> b) Easier and more natural for D newbies who've used C++ templates and/or 
>> C# / Java Generics.
>
> I agree.
>

This is probably the biggest issue since D has to win mindshare or else what 
is the point of this or any other discussion.

>> c) There can be no D code where ">>" instead of "> >" breaks existing 
>> code like C++98 vs C++0x.
>> d) There wouldn't be the "I hate it because it's not C++ enough" first 
>> impression for templates.
>
> I don't know if there's anyone arguing this, and I'm OK with !(...).
>
>> e) Less typing compared to current.
>
> Even less using the new a!b syntax.
>
>> f) Could make definition and instantiation consistent as well:
>> class C<T> {T val;}
>> auto c = new C<int>;
>
> This is an irrelevant design issue. D can be engineered to support
>
> class C!T {
>   T val;
> }
> auto c = new C!int;
>

Even more inconsistency and duplication <g>

> as well I believe, but the current implementation uses class C(T) instead. 
> (BTW, you've left out the “template <typename T>” line before the class 
> C<T> statement.)
>

I don't understand... I was talking about just replacing () and !() with the 
<> that C++, C# and Java use, not changing anything else regarding D 
template syntax.

>> g) I'm sure the same workaround could be used for D's UShr operator 
>> '>>>'.
>> h) Andrei will like it better because it's closer to chevrons <g>
>
> Me too «g»
>
>>
>> Also, as long as I'm thinking out of the box here, for D2 how about 
>> considering using a different group of symbols for bitwise shift (if for 
>> some reason the ambiguity issue is too large to work around)?
>>
>> Before you yell "Sacralidge!" and roll your eyes, consider that out of 
>> about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 have 
>> "!(.*)". Also, '>>>' is only used 25 times in phobos and could be 
>> replaced with '>>' and a cast where it is used.
>>
>> Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= 
>> (shrAssign)?
>>
>> Just a thought.
>>
>> Still there may be an issue with a<b,c>d, but again that is apparently 
>> solved in C#, Java  and C++0x, and I didn't find any of that used in 
>> phobos. I think the way they solved this in C# at least was to disallow 
>> the comma operator between conditional predicates, which I don't see as a 
>> huge issue.
>>
>> - Dave
>>