On Fri, Mar 10, 2017 at 07:47:43AM +0000, XavierAP via Digitalmars-d wrote: > On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote: [...] > > Maybe we want to support weird DSLs, where operators are reused with > > very different semantics? For example, the pyparsing parser > > generator allows you to write a grammar like [0] this: > > Maybe... I usually hate that stuff a-la-C++ iostream but, inverting > the question, do you want to disallow it?
AFAIK Walter's stance is that overloading operators with semantics other than generalizations of arithmetic operators are a bad idea. This is why D uses opCmp for overloading <, <=, ==, >=, >, instead of one overload per operator like C++ has. Separately overloading < and <=, for example, means that the programmer can do truly weird things with it, which makes code hard to read (when you see "a < b" and "a <= b", you have no idea what they *really* mean). For DSLs, the official D recommendation is to use string mixins and CTFE instead. This gives you the flexibility to use *any* syntax you want for your DSL, including syntax that doesn't even fit in D syntax. You could even implement Unicode operators. CTFE lets you parse such strings at compile-time and emit code for them via string mixins, so runtime performance is not a concern. And I would tend to agree: I find iostream's (ab)use of << and >> to mean anything other than bitshifting very ugly and hard to read. Look at the Boost.Xpressive library for an even more extreme example of this. (Though thankfully, they appear to be moving towards string DSLs by taking advantage of the latest C++ features, so there is hope that this will soon be just an ugly footnote in history.) A long-standing item on my todo list is to implement compile-time writefln format strings using this technique. I don't even want to imagine how ugly code will become if I were to do compile-time format strings the C++ way by overloading arithmetic operators... imagine format strings written using operators... Ugh! T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
