Hello!

Thanks for best language syntax! But templates.

Templates are traditional is {} or <>.

!(exclamation mark) sense/perceive as stop symbol, by my mean.

< and > is nice construction. May be add it in D?)

Again, big thanks for language!

On Wed, 30 Jan 2019 19:17:38 +0000, dronord wrote:
> Templates are traditional is {} or <>.

I've never seen {} for templates. I believe I've only seen [], <>, (), and !().

> < and > is nice construction. May be add it in D?)

D is a mature language, and part of that is not making changes without a good reason.

There is a good reason *not* to use <>: it's ambiguous. Consider:

    A<B> C;

This can be parsed as:

    alias SomeType = A<B>;
    SomeType C;

or:

    bool aLessThanB = A < B;
    aLessThanB > C;

Similarly, the expression:

    Func(A<B, C>(1));

could either be:

    auto tmp1 = A < B;
    auto tmp2 = C > (1);
    Func(tmp1, tmp2);

or:

    alias SomeFunc = A<B, C>;
    Func(SomeFunc(1));

It's generally considered bad if you have to defer parsing until you have semantic data available.

D didn't manage to eliminate the lexer hack, unfortunately.

On Wed, Jan 30, 2019 at 07:17:38PM +0000, dronord via Digitalmars-d wrote: [...]
> Templates are traditional is {} or <>.
> 
> !(exclamation mark) sense/perceive as stop symbol, by my mean.
> 
> < and > is nice construction. May be add it in D?)
[...]

The choice of ! for template instantiation may perhaps be challenged, but seriously, < and > for templates??!  That's one of the absolutely worst design choices C++ has ever made, which has made C++ infamous for being unlexable until it's parsed, not to mention produced utterly horrific unreadable template syntax.

Take for example this D snippet:

	auto myFunc(alias less, Args...)(Args args) { ... }
	myFunc!((a, b) => a < b)(...);

Try writing the second line with C++'s < and > syntax, and you get the monstrosity:

	myFunc<(a, b) => a < b>(...);

The real fun begins with nested templates:

	myFunc<nested<(a, b) => xform<(x, y) < z>(a) > xform<(x, y) < z>(b)>>(...);

Now your <'s and >'s have become unreadably ambiguous and virtually impossible to parse.

With !, it may not look so pretty, but at least it's not ambiguous:

	myFunc!(nested!((a, b) => xform!((x, y) < z)(a) > xform!((x, y) < z)(b)))(...);


Please, let's leave C++'s < > mistake in the dustbins of history. Such suffering ought not be inflicted upon our future generations.


T

-- 
"Hi." "'Lo."

On Wednesday, 30 January 2019 at 19:42:06 UTC, Neia Neutuladh wrote:
> D didn't manage to eliminate the lexer hack, unfortunately.

Huh, I thought it did since casts use a keyword and pointer-type declarations always supercede multiplication. Where does it fail?

On Wed, 30 Jan 2019 20:13:28 +0000, Dennis wrote:
> On Wednesday, 30 January 2019 at 19:42:06 UTC, Neia Neutuladh wrote:
>> D didn't manage to eliminate the lexer hack, unfortunately.
> 
> Huh, I thought it did since casts use a keyword and pointer-type declarations always supercede multiplication. Where does it fail?

Whoops, my mistake, it *does* fix the lexer hack.

On Wednesday, 30 January 2019 at 19:17:38 UTC, dronord wrote:
> Hello!
>
> Thanks for best language syntax! But templates.
>
> Templates are traditional is {} or <>.
>
> !(exclamation mark) sense/perceive as stop symbol, by my mean.
>
> < and > is nice construction. May be add it in D?)
>
> Again, big thanks for language!

< and > used as brackets is completely brain dead. Here a little example in C++ showing why

fon< fun< 1 >>::three >::two >::one

what doas it mean? (i.e. how is it parsed).

Answer: it depends. It doesn't parse the same under C++98 or C++11.

fon< fun< 1 >>::three >::two >::one    // in C++98
          -----------
     -----------------------
-----------------------------------

and

fon< fun< 1 >>::three >::two >::one    // in C++11
     --------
---------------------
----------------------------
-----------------------------------

and to avoid this catastrophic parsing nightmare, D chose a syntax that is not ambiguous.

https://gustedt.wordpress.com/2013/12/18/right-angle-brackets-shifting-semantics/#more-2083

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

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

On 1/30/2019 11:42 AM, Neia Neutuladh wrote:
> D didn't manage to eliminate the lexer hack, unfortunately.

??

On 1/30/2019 12:12 PM, H. S. Teoh wrote:
> Please, let's leave C++'s < > mistake in the dustbins of history. Such
> suffering ought not be inflicted upon our future generations.

To pile it on, C++ iostreams overloads << and >> operators.