Template instantiation syntax

KennyTM~ kennytm at gmail.com
Sat Oct 11 10:29:48 PDT 2008


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.

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.

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

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

I agree.

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

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

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



More information about the Digitalmars-d mailing list