Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

XavierAP via Digitalmars-d digitalmars-d at puremagic.com
Fri Mar 10 13:07:36 PST 2017


On Friday, 10 March 2017 at 19:02:06 UTC, H. S. Teoh wrote:
> 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).

* D does not use opCmp for == but I'm sure it slipped your tongue 
;)

I agree with that stance on style myself, and also with the hard 
restriction to keep the (in)equality and comparison operators 
consistent with each other. But the question is whether to 
restrict programmers further with no other reason than style. D's 
philosophy is maximum @system freedom (just like C/C++) within 
sanity.

Also operator overloading style may depend on each engineer's 
background. Walter's education is mechanical engineering and 
mathematics (coincidentally just like myself), so he dislikes 
usage of operators not analogous to algebra or set theory. Me 
too; beyond that I would rather create methods with 
self-documenting names.

But there are software engineers and computer scientists who 
don't care about math, and they may even love iostream's "arrows" 
indicating the direction of the "stream". Leaving aside the 
specific example of iostream, this style discussion is not one 
where anyone can prove or claim to be right. Live and let live.


More information about the Digitalmars-d mailing list