Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[qznc via Digitalmars-d]

On Tuesday, 7 March 2017 at 15:34:54 UTC, ketmar wrote:
> Jack Stouffer wrote:
>
>> On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote:
>>> only for primitive types, sadly.
>>>
>>> void main () {
>>> Object a, b;
>>> a == b;
>>> }
>>>
>>> oops. no more error messages. yes, i know that this invokes 
>>> `opEquals()`, and `opEquals()` can have side-effects. but 
>>> what are the chances of writing such code *intentionally*?
>>
>> Hmm, I guess the compiler can (and should) output an error 
>> message if it knows that opEquals is `pure`.
>>
>> https://issues.dlang.org/show_bug.cgi?id=17245
>
> yet Object's `opEquals()` is not pure (and it cannot be, to 
> allow non-pure overloads). still, the code i've written has no 
> sense.

I'm curious. Where does it make sense for opEquals to be 
non-pure? Likewise opCmp, etc.

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:

   exp << Group(lparen + op + (number | exp) + (number | exp) + 
rparen)

[0] 
http://pyparsing.wikispaces.com/file/view/pycalc.py/480674428/pycalc.py