Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[H. S. Teoh via Digitalmars-d]

On Fri, Mar 10, 2017 at 03:45:37AM +0000, Ivan Kazmenko via Digitalmars-d wrote:
> On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
> > I'm curious. Where does it make sense for opEquals to be non-pure?
> > Likewise opCmp, etc.
> 
> An example would be tracking the number of comparisons made.  This
> sounds like debug information (and then, debug statement can be used
> to escape purity), but perhaps may be applied beyond simple debugging
> and profiling.
[...]

The main practical use case I can think of is caching, e.g., if
computing the (in)equality is expensive and you want to cache the result
if the comparison is frequently made.

But opEquals/opCmp being non-pure has been a big hindrance in the uptake
of pure (and other attributes), because of the way the Object base class
defines these methods, and since it was originally done before some of
these attributes existed in the language, some derived classes may
already depend on them being impure / throwing / etc., so changing it
now would break code.

Besides, if Object declares opEquals as pure, then *all* classes would
be required to declare it as pure, which may be an onerous limitation.


T

-- 
This is a tpyo.