strong_typedef of user-defined types with non-constexpr operators about type_safe HOT 9 CLOSED

In your example, the call can never be constexpr, so clang is wrong.

The type_safe::strong_typedef_ops, however, are templated. This means that calling them in non-constant expressions should not fail just because they can't be evaluated in constant expressions.

from type_safe.

I had a discussion with on the C++ slack: MSVC is - surprisingly - correct by rejecting it.
I have to create free templated functions that are disabled unless a type inherits from the appropriate strong_typedef_op.

from type_safe.

Do you mean that MSVC is correct in the given example, or in the described case of a user-defined type with non-constexpr operators? Or both (and I have given wrong information :()? If its the second case, could you elaborate?

from type_safe.

If I understand the slack discussion correctly:

1. The mixins are templated classes, but the friend functions defined in them are not, so MSVC is correct in rejecting it.
2. clang is not wrong in accepting it, as no diagnostic is required.

from type_safe.

@JohelEGP If you have a non-template constexpr function it must only use constexpr functions/types/..., so MSVC correctly rejects it as the called operator== is not constexpr.

from type_safe.

@tJener

1. That's right. What I said about not failing only applies to function templates. See [dcl.constexpr]/6 (emphasis mine):

If the instantiated template specialization of a constexpr function template or member function of a class template would fail to satisfy the requirements for a constexpr function or constexpr constructor, that specialization is still a constexpr function or constexpr constructor, even though a call to such a function cannot appear in a constant expression. If no specialization of the template would satisfy the requirements for a constexpr function or constexpr constructor when considered as a non-template function or constructor, the template is ill-formed; no diagnostic required.

2. You're right. I should have used C++ terminology, rather than ambiguous words such as failing or wrong.

@foonathan Given the above, it should be okay to leave the strong_typedef_ops in the structs and template them on the StrongTypedef template argument and disable if they're not the same type. I don't have much experience with it, but I've read that having free template functions can cause some noise.

from type_safe.

Regarding 7c963a8, I think you need to switch the StrongTypedef parameters with T so that it becomes dependent, if it isn't already.

from type_safe.

Can't get that too work, complains about duplicate definitions.

Have to do the "write free template functions, enable_if derived" trickery. Working on that, I hope I can finally fix it together, but probably with some breaking changes.

from type_safe.

Alright, I finally got something that seems to work.

from type_safe.