Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[H. S. Teoh via Digitalmars-d]

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