https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6

The error is here:

    https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...

and the line of code:

    zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;

In other words, a statement with no effect. In D, such a line gives an error, not a warning:

    Error: == has no effect in expression

On Tuesday, 7 March 2017 at 05:44:49 UTC, Walter Bright wrote:
> https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6
>
> The error is here:
>
>     https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...
>
> and the line of code:
>
>     zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;
>
> In other words, a statement with no effect. In D, such a line gives an error, not a warning:
>
>     Error: == has no effect in expression

To be fair, this also would have been caught with proper testing ... which obviously didn't happen.

OT from D:

Run screaming in the other direction of this shit. For this to pass through I wouldn't trust these devs with $10, let alone any of my financial security. I still have trust issues with coinbase, let alone some fly-by-night custom bitcoin derivative.

On 3/6/2017 10:06 PM, Jack Stouffer wrote:
> To be fair, this also would have been caught with proper testing ... which
> obviously didn't happen.

My idea of fair is it should never have gotten past the compiler. It's a simple mistake for the compiler to detect.

Walter Bright wrote:

> https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6
>
> The error is here:
>
> https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...
>
> and the line of code:
>
> zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;
>
> In other words, a statement with no effect. In D, such a line gives an error, not a warning:
>
> Error: == has no effect in expression

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*?

i guess, compiler should emit error for *any* usage of "==" without using the result, even if it lowers to `opEquals()` or something. and if one really want to use it and drop it's result, there is always escape path:

 cast(void)(a == b);

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

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.

On Tuesday, 7 March 2017 at 06:59:38 UTC, Walter Bright wrote:
> On 3/6/2017 10:06 PM, Jack Stouffer wrote:
>> To be fair, this also would have been caught with proper testing ... which
>> obviously didn't happen.
>
> My idea of fair is it should never have gotten past the compiler. It's a simple mistake for the compiler to detect.

clang 3.9.1 with 0 flags used:

$ cat zcoin.cpp
int main() {
    int a, b;
    a == b;
}
$ clang++ zcoin.cpp

zcoin.cpp:3:7: warning: equality comparison result unused [-Wunused-comparison]
    a == b;
    ~~^~~~
zcoin.cpp:3:7: note: use '=' to turn this equality comparison into an assignment
    a == b;
      ^~
      =
1 warning generated.

gcc, sadly, warns about nothing by default but does with `-Wall`. But... anyone not using `-Wall -Wextra -Werror` on a new C++ codebase shouldn't be writing C++ AFAIC*. And then there's the aforementioned lack of adequate testing.

Does D do better? Sort of (clang issues a warning, which I know can be and is often ignored). Is this an example of amateur hour by the Zcoin devs? Indubitably.

Atila

* Maybe there should be something like a driver's license for C++ where devs have to pass a test before they're allowed to write code. Something like "Do you know how to use std::enable_if without looking at cppreference.com? No? Fail." (I'd fail, I _always_ have to look up how to use enable_if. Then again, it _is_ a horrible hacky hack of a hack based on the hack that is SNIFAE).

On 3/7/2017 9:45 AM, Atila Neves wrote:
> 1 warning generated.

Pretty much all C++ compilers will generate warnings for this. The thing about warnings, though, is they imply that there are situations where the code is acceptable. I can't think of any. It needs to be an error. It should never pass the compiler.


> Does D do better?

Yes, it's an error in D.

On Tuesday, 7 March 2017 at 05:44:49 UTC, Walter Bright wrote:
> https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6
>
> The error is here:
>
>     https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...
>
> and the line of code:
>
>     zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;
>
> In other words, a statement with no effect. In D, such a line gives an error, not a warning:
>
>     Error: == has no effect in expression

Coincidentally, saw this in https://www.youtube.com/watch?v=A8Btr8TPJ8c&feature=youtu.be&t=469, while watching DConf 2015. No one spotted this bug (wasFound) in the conf?

On Tuesday, 7 March 2017 at 17:45:13 UTC, Atila Neves wrote:
> write code. Something like "Do you know how to use std::enable_if without looking at cppreference.com? No? Fail." (I'd fail, I _always_ have to look up how to use enable_if. Then again, it _is_ a horrible hacky hack of a hack based on the hack that is SNIFAE).

"std::enable_if" is a hack, but I don't think the underlying principle of SFINAE is a hack as such, although it isn't principled in C++... SFINAE basically allows deduction and pattern matching at some level, which is what turned it into a useful programming mechanism. And those can be desirable features.

Of course the syntax isn't great for the casual reader, e.g.:

"template<T, typename std:enable_if_t<T == MyType, int> == 0> ..."

But the crux to making C++ code readable is to use a smaller set of general formulations, make those idioms and avoid all the alternative ways that are less general.

void_t is kinda neat:

"template<typename T, typename = void_t<>>struct mystuff ..."
"template<typename T> struct mystuff<T, void_t<A> > ..."
"template<typename T> struct mystuff<T, void_t<B> > ..."