Template instantiation syntax

[KennyTM~]

Dave wrote:
> "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>
> 

lol.

> 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.
> 

I thought you argued

class C(T) { T val; }
auto c = new C!(int);

is inconsistent because in definition you used (...) but in usage you 
used !(...) ?

>>> 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
>>>
>