Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[XavierAP via Digitalmars-d]

On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
> 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.

I my experience it is a bad idea to require such restrictive 
contracts at lower inheritance levels when others outside a 
library are supposed to inherit your class. My case was a 
calculation object in C++, a calculation is a mathematical 
formula, so in the base class I made the method const, and the 
simple implementation inside had no problems with that. But a big 
project plugged into the rest of calculations in the library, 
while overriding this calculation with its own FEM engine, which 
is expensive to run, and should be cached. I had to redesign the 
library and remove that const. So result caching is indeed an 
example, like HS Teoh said.

Going back to the original question above, if you really want the 
compiler to complain about a==b statements for custom types, 
rather than forcing opEquals to be pure, it would make more sense 
for the compiler to define which operator overloads are allowed 
in this way (++, --, etc) and which aren't (==, +, -, 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:

Maybe... I usually hate that stuff a-la-C++ iostream but, 
inverting the question, do you want to disallow it?