www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - template syntax

reply dronord <dronord gmail.com> writes:
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!
Jan 30
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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.
Jan 30
next sibling parent reply Dennis <dkorpel gmail.com> writes:
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?
Jan 30
parent Neia Neutuladh <neia ikeran.org> writes:
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.
Jan 30
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2019 11:42 AM, Neia Neutuladh wrote:
 D didn't manage to eliminate the lexer hack, unfortunately.
??
Jan 30
prev sibling parent reply bpr <brogoff gmail.com> writes:
On Wednesday, 30 January 2019 at 19:42:06 UTC, Neia Neutuladh 
wrote:
 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 !().
Julia uses the curly brackets for type parameterization.
 < 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.
I much prefer the D template syntax even though I'm way more used to '<>' from C++, Java, and Rust. If I were going to make a change in syntax to D3 I'd make variable declaration syntax postfix, like Go, Scala, Kotlin, Rust...
Feb 03
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 3 February 2019 at 19:37:57 UTC, bpr wrote:
 I much prefer the D template syntax even though I'm way more 
 used to '<>' from C++, Java, and Rust. If I were going to make 
 a change in syntax to D3 I'd make variable declaration syntax 
 postfix, like Go, Scala, Kotlin, Rust...
I hope that does not happen. I absolutely hate it.
Feb 03
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Monday, 4 February 2019 at 07:19:32 UTC, bauss wrote:
 On Sunday, 3 February 2019 at 19:37:57 UTC, bpr wrote:
 I much prefer the D template syntax even though I'm way more 
 used to '<>' from C++, Java, and Rust. If I were going to make 
 a change in syntax to D3 I'd make variable declaration syntax 
 postfix, like Go, Scala, Kotlin, Rust...
I hope that does not happen. I absolutely hate it.
Tell us more. I've thought about this one but haven't been able to determine if either method is objectively better. How do you think each method would affect a language in general?
Feb 04
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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."
Jan 30
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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 :-)
Jan 30
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 30
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2019 1:28 PM, H. S. Teoh wrote:
 Recent versions of C++ ostensibly have "solved" that problem, so that no
 intervening space is needed anymore.
I implemented the lexer hack back in the 90's, but had to back it out to get it through the C++98 test suite. Then, I had to add it back in to match later C++ Standards :-)
 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.
I think the .template syntax is to work around such a corner case.
Jan 30
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/30/19 4:57 PM, Walter Bright wrote:
 On 1/30/2019 1:28 PM, H. S. Teoh wrote:
 Recent versions of C++ ostensibly have "solved" that problem, so that no
 intervening space is needed anymore.
I implemented the lexer hack back in the 90's, but had to back it out to get it through the C++98 test suite. Then, I had to add it back in to match later C++ Standards :-)
 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.
I think the .template syntax is to work around such a corner case.
Don't forget "typename" and "::template", beautifully combined here: typedef typename Allocator::template rebind<Mapped>::other mapped_type_allocator; Andrei
Jan 30
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully combined here:
 
 typedef typename Allocator::template rebind<Mapped>::other
mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
Jan 30
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 30, 2019 at 05:11:07PM -0800, Walter Bright via Digitalmars-d wrote:
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully combined here:
 
 typedef typename Allocator::template rebind<Mapped>::other
mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
I second! And while we're at it, how about reinstating the comma operator and introducing opComma, and additionally opLess, opLessEqual, opGreater, opGreaterEqual, opNotEqual, and opDot? It will be greatly helpful with a library implementation of < > syntax, which will be an important step to gauge how useful it will be in practice, and could in the meantime serve as a good substitute in lieu of a complicated in-compiler implementation. T -- Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright
Jan 30
next sibling parent bauss <jj_1337 live.dk> writes:
On Thursday, 31 January 2019 at 01:28:29 UTC, H. S. Teoh wrote:
 And while we're at it, how about reinstating the comma operator 
 and introducing opComma, and additionally opLess, opLessEqual, 
 opGreater, opGreaterEqual, opNotEqual, and opDot?  It will be 
 greatly helpful with a library implementation of < > syntax, 
 which will be an important step to gauge how useful it will be 
 in practice, and could in the meantime serve as a good 
 substitute in lieu of a complicated in-compiler implementation.


 T
Also an opAnd
Jan 31
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 31 January 2019 at 01:28:29 UTC, H. S. Teoh wrote:
 On Wed, Jan 30, 2019 at 05:11:07PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully 
 combined here:
 
 typedef typename Allocator::template rebind<Mapped>::other 
 mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
I second! And while we're at it, how about reinstating the comma operator and introducing opComma, and additionally opLess, opLessEqual, opGreater, opGreaterEqual, opNotEqual, and opDot? It will be greatly helpful with a library implementation of < > syntax, which will be an important step to gauge how useful it will be in practice, and could in the meantime serve as a good substitute in lieu of a complicated in-compiler implementation. T
FWIW opDot still exists in DMD as of 2.084.0 (and nightly): https://github.com/dlang/dmd/blob/2457038c1ac37fbe1098b4b3d98007761149dfaf/test/runnable/xtest46.d#L130 It's just deprecated. We don't have opGreater/opEqual, but there's still opAnd: https://github.com/dlang/dmd/blob/06d3770d3baf51ce0b4b9998bf6a4e0369ee8f02/test/runnable/opover.d In fact all these old D1 operator overloads (opPos,opNeg,..., opShl, opShr,..., opMul_r) are still supported in DMD and don't even trigger a deprecation message: https://github.com/dlang/dmd/blob/06d3770d3baf51ce0b4b9998bf6a4e0369ee8f02/src/dmd/id.d#L206
Jan 31
parent bauss <jj_1337 live.dk> writes:
On Thursday, 31 January 2019 at 13:01:09 UTC, Seb wrote:
 On Thursday, 31 January 2019 at 01:28:29 UTC, H. S. Teoh wrote:
 On Wed, Jan 30, 2019 at 05:11:07PM -0800, Walter Bright via 
 Digitalmars-d wrote:
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully 
 combined here:
 
 typedef typename Allocator::template rebind<Mapped>::other 
 mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
I second! And while we're at it, how about reinstating the comma operator and introducing opComma, and additionally opLess, opLessEqual, opGreater, opGreaterEqual, opNotEqual, and opDot? It will be greatly helpful with a library implementation of <
 syntax, which will be an important step to gauge how useful
it will be in practice, and could in the meantime serve as a good substitute in lieu of a complicated in-compiler implementation. T
FWIW opDot still exists in DMD as of 2.084.0 (and nightly): https://github.com/dlang/dmd/blob/2457038c1ac37fbe1098b4b3d98007761149dfaf/test/runnable/xtest46.d#L130 It's just deprecated. We don't have opGreater/opEqual, but there's still opAnd: https://github.com/dlang/dmd/blob/06d3770d3baf51ce0b4b9998bf6a4e0369ee8f02/test/runnable/opover.d In fact all these old D1 operator overloads (opPos,opNeg,..., opShl, opShr,..., opMul_r) are still supported in DMD and don't even trigger a deprecation message: https://github.com/dlang/dmd/blob/06d3770d3baf51ce0b4b9998bf6a4e0369ee8f02/src/dmd/id.d#L206
Someone needs to do some cleanup.
Jan 31
prev sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Wed, Jan 30, 2019 at 5:15 PM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully combined here:

 typedef typename Allocator::template rebind<Mapped>::other
mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
Bauss will win another worst code contest if this DIP gets approved ;-)
Jan 30
parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 31 January 2019 at 01:30:36 UTC, Arun Chandrasekaran 
wrote:
 On Wed, Jan 30, 2019 at 5:15 PM Walter Bright via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully 
 combined here:

 typedef typename Allocator::template rebind<Mapped>::other 
 mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
Bauss will win another worst code contest if this DIP gets approved ;-)
I can't wait! ;)
Jan 31
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 31, 2019 at 01:13:29PM +0000, bauss via Digitalmars-d wrote:
 On Thursday, 31 January 2019 at 01:30:36 UTC, Arun Chandrasekaran wrote:
 On Wed, Jan 30, 2019 at 5:15 PM Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully combined
 here:

 typedef typename Allocator::template rebind<Mapped>::other
 mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to < > ?
Bauss will win another worst code contest if this DIP gets approved ;-)
I can't wait! ;)
One of these days I'm gonna hafta pull an IODCC entry... Like the monstrosity I recently posted in bauss's thread. :-D T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
Jan 31
parent bauss <jj_1337 live.dk> writes:
On Thursday, 31 January 2019 at 17:31:02 UTC, H. S. Teoh wrote:
 On Thu, Jan 31, 2019 at 01:13:29PM +0000, bauss via 
 Digitalmars-d wrote:
 On Thursday, 31 January 2019 at 01:30:36 UTC, Arun 
 Chandrasekaran wrote:
 On Wed, Jan 30, 2019 at 5:15 PM Walter Bright via 
 Digitalmars-d <digitalmars-d puremagic.com> wrote:
 
 On 1/30/2019 4:08 PM, Andrei Alexandrescu wrote:
 Don't forget "typename" and "::template", beautifully 
 combined here:

 typedef typename Allocator::template 
 rebind<Mapped>::other mapped_type_allocator;
It is indeed beautiful. Want to write a DIP to switch to <
 ?
Bauss will win another worst code contest if this DIP gets approved ;-)
I can't wait! ;)
One of these days I'm gonna hafta pull an IODCC entry... Like the monstrosity I recently posted in bauss's thread. :-D T
Please make my dream come true
Feb 01
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 30, 2019 at 01:28:39PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
 	myFunc<T, U>(a, b);
[...] OK, so I decided to amuse myself a little today, and worked out the fully-compilable C++ code that showcases exactly the above line doing something completely different from what you might think it does. First, take a look at main() at the bottom, especially the last two lines. Now see if you can figure out what they do. Compile and run it yourself to find out what it actually does. :-D Now imagine if you inherited this code from an ex-employee and are now responsible for maintaining it. Good luck! -----------------------------------snip------------------------------------ // Totally evil example of why C++ template syntax and free-for-all operator // overloading is a Bad, Bad Idea. #include <iostream> struct Bad { }; struct B { }; struct A { Bad operator,(B b) { return Bad(); } }; struct D { }; struct Ugly { D operator>(Bad b) { return D(); } } U; struct Terrible { } T; struct Evil { ~Evil() { std::cout << "Hard drive reformatted." << std::endl; } }; struct Nasty { Evil operator,(D d) { return Evil(); } }; struct Idea { void operator()(A a, B b) { std::cout << "Good idea, data saved." << std::endl; } Nasty operator<(Terrible t) { return Nasty(); } } gun; template<typename T, typename U> void fun(A a, B b) { std::cout << "Have fun!" << std::endl; } int main() { A a; B b; // What do these lines do? fun<A, B>(a, b); gun<T, U>(a, b); } -----------------------------------snip------------------------------------ T -- To provoke is to call someone stupid; to argue is to call each other stupid.
Jan 30
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 30
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 30, 2019 at 01:54:47PM -0800, Walter Bright via Digitalmars-d wrote:
 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.
Sigh, you made me do it. Couldn't resist: #include <iostream> struct Sigh { }; struct You { Sigh operator>>(std::string s) { return Sigh(); } } U; struct Me { }; struct Do { Me operator<(Sigh m) { return Me(); } } traits; struct It { } T; struct Couldnt { void operator,(Me i) { std::cout << "Goodbye, earth" << std::endl; } }; struct Resist { void operator()(std::string msg) { std::cout << msg << std::endl; } Couldnt operator<(It t) { return Couldnt(); } } fun; int main() { // What does this line do? fun<T, traits<U>>("Hello world"); } :-D T -- Never trust an operating system you don't have source for! -- Martin Schulze
Jan 30
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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
Jan 30