template syntax

[H. S. Teoh]

On Wed, Jan 30, 2019 at 08:51:24PM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Wednesday, 30 January 2019 at 20:12:13 UTC, H. S. Teoh wrote:
> > On Wed, Jan 30, 2019 at 07:17:38PM +0000, dronord via Digitalmars-d
> > wrote: [...]
> 
> > The real fun begins with nested templates:
> > 
> > 	myFunc<nested<(a, b) => xform<(x, y) < z>(a) > xform<(x, y) <
> > z>(b)>>(...);
> > 
> 
> I hope you didn't forget the space between the >'s. Or else it might
> shift some value somewhere :-)

Recent versions of C++ ostensibly have "solved" that problem, so that no
intervening space is needed anymore.

Of course, that doesn't really solve the problem; it only introduces
more complexity in the parser / lexer, and in all likelihood more
pathological corner cases to come back and bite you when you least
expect it.  (Just like, sorry to say, many of C++'s other recent
additions that try to patch over legacy design flaws, but end up making
things worse in other ways.)  Like, if certain symbols are defined
differently, the >> could actually become a bit-shift operator. And with
free-for-all operator overloading, who knows *what* that would actually
mean semantically.

Here's another example of why < and > ambiguity is so evil: take this
innocent-looking expression:

	myFunc<T, U>(a, b);

Since C++ allows you to overload the comma operator, myFunc could be an
object that overloads operator<(), and

	myFunc<T

returns an object that then combines via operator,() with U to produce
another object that is then compared via > with the result of another
comma operator overload that returns a third object for (a, b).

I.e., the above line could actually be parsed as:

	((myFunc < T) , U) > (a, b);

in spite of looking like calling a template function.  Don't you just
love C++??!


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen