Do not use `static_assert()` to prevent template instantation errors

[bobsteagall]

Do not use `static_assert()` to prevent template instantation errors

[BobSteagall]

What is the offending code that caused the failure? That static assert is there for a reason -- if it fires, then the dimensions of the multiplication don't line up, and multiplication is not possible.

[mpusz]

This is not the only overload participating in the overload resolution. The compiler can't choose the correct one because static_assert() aborts the instantiation of an invalid overload.

[mpusz]

BTW, there are many other similar problems like that with this library. We have to meet at some point and work together to try to resolve those. Until then I recommend testing the library with various custom representation types.

[BobSteagall]

I need some example code to test against.

[dwith-ts]

The offending traits are in the body of the method but the method has an auto return type. As @mpusz is using decltype() with that method the compiler needs to look at the method body to determine the return type which fires the static assert. L

For a normal method call it would probably work.

[mpusz]

I understand, but I can't provide it now as my code base is not stable. When it is on the mainline, I will provide one.

In the meantime, here is a simple code showing why static_assert() is a really bad idea: https://godbolt.org/z/v4qPxP5EW and should not be used. If the check is really needed use concepts to prevent the instantiation rather then abort while instantiating the type.

[BobSteagall]

Yes, but overload resolution is not the source of the static_assert failing in your Godbolt example; the definition of foo(double) is. Comment out the call to foo in main and compilation still fails.

If I understand correctly, what you're saying is that overload resolution in your code is trying to resolve at least one overload whose matrix dimensions are incompatible with multiplication. And that overload is causing the static_assert to fail.

And so my question is this -- how is it that you have an overload where you are trying to multiply two matrices with incompatible dimensions? This is why I wanted to see an example.

[BobSteagall]

Note that I am not disagreeing with your statements about using concepts -vs- static assert. I am however trying to understand the source of the static_assert failure.

[dwith-ts]

The offending traits are in the body of the method but the method has an auto return type. As @mpusz is using decltype() with that method the compiler needs to look at the method body to determine the return type which fires the static assert. L

For a normal method call it would probably work.

As I said, I strongly suspect that it’s a decltype usage (not an actual call, see the error output) in @mpusz’s code and the usage of an auto return type in @BobSteagall’s code which means the method body has to be instantiated to infer the return type which causes the static assert.

[BobSteagall]

As I said, I strongly suspect that it’s a decltype usage (not an actual call, see the error output) in @mpusz’s code and the usage of an auto return type in @BobSteagall’s code which means the method body has to be instantiated to infer the return type which causes the static assert.

Yes, quite possibly true. But that begs the question -- decltype of what? Of a multiplication with incompatible dimensions?

[BobSteagall]

In fact, as I look at the error messages, it appears to be an attempt to multiply a 3x1 matrix by a 3x1 matrix, which is incompatible.

[dwith-ts]

As I said, I strongly suspect that it’s a decltype usage (not an actual call, see the error output) in @mpusz’s code and the usage of an auto return type in @BobSteagall’s code which means the method body has to be instantiated to infer the return type which causes the static assert.

Yes, quite possibly true. But that begs the question -- decltype of what? Of a multiplication with incompatible dimensions?

This is a multiplication of a vector with a physical unit from @mpusz’s library, so the multiplication from that library is supposed to be used IMHO. However, when the compiler determines the viable candidates for the operator* overload set (due to invoke_result / decltype usage) it needs the return type of all of these methods. And in order to determine its return type it needs to instantiate the method (because it has an auto return type) even though it will not be selected in the end.
At least that’s my understanding.

[mpusz]

What is the offending code that caused the failure? That static assert is there for a reason -- if it fires, then the dimensions of the multiplication don't line up, and multiplication is not possible.

The offending code is:

template<typename Rep = double>
using vector = STD_LA::fixed_size_column_vector<Rep, 3>;

Quantity auto v = make_quantity<isq::position_vector[m]>(vector<int>{1, 2, 3});
std::cout << "2 * v = " << 2 * v << "\n";

There is NO matrix * matrix multiplication here. My understanding is that there are a few overloads in the overload set and one of them aborts the compilation even though it is not a valid match anyway.

I need some example code to test against.

As I wrote before, my code is not ready to share now :-( However, the function that is being called here is just:

  template<typename Value>
    requires(!Quantity<Value>) && detail::InvokeResultOf<quantity_spec.character, std::multiplies<>, const Value&, rep>
  [[nodiscard]] friend constexpr Quantity auto operator*(const Value& v, const quantity& q)
  {
    return make_quantity<reference>(v * q.number());
  }

[BobSteagall]

What are the types of Value and rep? Are they both 3x1 matrices?

[mpusz]

Value = int
rep = STD_LA::fixed_size_column_vector<int, 3>

[mpusz]

Today I came back to LA and found the cause of static_assert():

https://github.com/mpusz/units/blob/b7e467ff42eb95dbefcf4c835b64d3a8760be3be/src/core/include/mp-units/bits/sudo_cast.h#L73

If LA types and operators were guarded with concepts rather than static_assert(), this code would compile fine.