Try to be more `explicit`

[johnmcfarlane]

Consider:

static_assert(identical(
        elastic_fixed_point<2, 2>{1.5} << 1,
        elastic_fixed_point<2, 2>{3}));

Looks OK right? But increase the shiftage:

static_assert(identical(
        elastic_fixed_point<2, 2>{1.5} << 123,
        elastic_fixed_point<2, 2>{3}));

Oh no, it still compiles! Trick! The exponent is 2 so both sides of the equality are zero.

int would never allow you to do that:

static_assert(int(0.5f) == int(.25f), "");
static_assert(int{0.5f} == int{.25f}, "");

This doesn't compile because float to int narrows and curlies don't allow that. We cannot eliminate all gotchas like the elastic_fixed_point one above. But we may avoid lulling the user into a false sense of security by matching what fundamental types do a little more closely.

[johnmcfarlane]

Another good example of where expectation is confounded is:

auto n = elastic_integer<5>{elastic_integer<10>{1000}};

[johnmcfarlane]

C++20 helps: http://en.cppreference.com/w/cpp/language/explicit

[johnmcfarlane]

For previous revisions use techniques described in P0892.

[danieagle]

Hi John! I'll will try correct this issue and issues quoted here. You have a check list and or any advice to give me? I'll target c++20.

Thanks in Avance, Dani. :-)

[johnmcfarlane]

Hi @danieagle this might not be the most straight-forward issue to fix right away. Library needs upgrading to C++20 before the explicit(expression) form can be used. There might be easier issues to tackle. And did you mention you had some repros that could be turned into issues. Perhaps they could be branches with new tests that fail -- TDD-style.

[danieagle]

Hi! Ok! I'll do it. :-) Really(!) Thanks!

[]'s Dani. :-)

[johnmcfarlane]

Possibly related is the ambiguity reported by compiler here.

[johnmcfarlane]

May result in removal of hicpp-explicit-conversions and google-explicit-constructor deviations.