script: Disallow silent bool -> CScript conversion #18621

Makes nonsensical stuff like ScriptToAsmStr(false,false); a compile failure

ACK 88884ee8d8dcd5303b20e54801b03f9631959c76

ACK 88884ee8d8dcd5303b20e54801b03f9631959c76.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #18612 (script: Remove undocumented and unused operator+ by MarcoFalke)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

ACK 88884ee8d8dcd5303b20e54801b03f9631959c76

explicit is better than implicit.

More generally I think we should err on the safe side and only allow implicit conversions via explicit opt-in (instead of disallowing via explicit opt-out) :)

ACK 88884ee8d8dcd5303b20e54801b03f9631959c76

Code review ACK 88884ee8d8dcd5303b20e54801b03f9631959c76

I think it's not possible for just marking a constructor explicit to change which overload a compiler chooses like sipa was speculating about in https://github.com/bitcoin/bitcoin/pull/18612/files#r407269834 (assuming no sfinae overloads). But might be worth verifying this PR doesn't change compiler output.

But might be worth verifying this PR doesn't change compiler output.

I get the same bin with gcc/clang on O2

@ryanofsky FWIW, that is not true in general.

The following code

#include <stdio.h>

struct A { };
struct B : public A { };
struct C {
    C(const A&) {printf("A\n");}
    C(const B&) {printf("B\n");}
};

int main(void) {
    const B objb = B();
    const C objc = objb;

    return 0;
}

will print B. When the C::C(const B&) constructor is marked explicit, it prints A. So it seems that:

• Explicit constructors only match in explicit contexts.
• deleted functions/constructors match just as much as non-deleted ones.
• Among all matching functions the most specific one is chosen.
• If the most specific one is deleted, there is an error.

utACK 88884ee8d8dcd5303b20e54801b03f9631959c76

@ryanofsky FWIW, that is not true in general.

Thanks, makes sense! I was thinking implicit constructor conversions would be pretty low in precedence but it makes sense derived-to-base conversions are lower