Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 30, 2019 template syntax | ||||
---|---|---|---|---|
| ||||
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! |
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to dronord | 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. |
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to dronord | 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." |
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | 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?
|
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dennis | 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.
|
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to dronord | 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 |
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 :-) |
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | 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 |
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Neia Neutuladh | On 1/30/2019 11:42 AM, Neia Neutuladh wrote:
> D didn't manage to eliminate the lexer hack, unfortunately.
??
|
January 30, 2019 Re: template syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
Copyright © 1999-2021 by the D Language Foundation