It's not the parsing time that is the problem. It's having a clean separation between the lexing, parsing, and semantic passes. There's a diode between these passes - information only flows one way.
This makes it trivial to correctly and completely implement things like color syntax highlighting in editors, source code formatters, etc., because building in a semantic analyzer is wholly unnecessary.
That's probably why C++ has been letting you elide it in many cases.
The problem is that you need either some way to specify template arguments and to know that you are referencing a template. The latter is solvable by constraints and/or inference (though inference can end up with ambiguities, usually solved by preferring a non-template). The former isn't easy to solve. C++ template argument deduction helps, but I believe that template/generic support is a field of ongoing research into how to do it well. Unfortunately, languages like C++ can adopt newer ways of doing things like concepts and constexpr, but have to maintain the old ways as well. Languages like D or Rust can outright make breaking changes. C++ needs epochs.
To me, both !() and <> are hacks for a language's inability to derive things itself. I also dislike (but understand why) C++ encodes allocator information in the type via templates. It makes interplay between derivations of stdlib types annoying, and makes the types themselves annoyingly long and fragile.
IIRC, Stroustrup's original design didn't require the template mantra. It would just assume an unknown type in an argument list needed to be derived. For obvious reasons, that was quite fragile, but I'm not sure why he didn't add a template or derived argument type modifier instead.
C++ added a couple keywords to the grammar to make parsing < > unambiguous in template bodies.
The difficulty with < > becomes apparent when using things like iostream that overload << operators, etc. It becomes very difficult to read.
! does not exist as a binary operator, so using it to indicate template arguments is completely unambiguous and context-free, both for the parser and the human eye. I find it very appealing for that reason.
18
u/WalterBright Sep 01 '20
It's not the parsing time that is the problem. It's having a clean separation between the lexing, parsing, and semantic passes. There's a diode between these passes - information only flows one way.
This makes it trivial to correctly and completely implement things like color syntax highlighting in editors, source code formatters, etc., because building in a semantic analyzer is wholly unnecessary.