Closed JohelEGP closed 5 years ago
I'm not so sure about 23eba91. When used with a single argument, the traits operate semantically equivalently to an ISO unary trait. Allowing multiple arguments just improves the readability when you want to check multiple types, but in my opinion the semantics are still equally clear. I think the standard is unnecessarily limiting in this case, and wasn't written with variadic templates in mind.
That said, I'm not necessarily against it and I'd like to understand your rationale.
Edit: separately, which parts of the traits did you fail to improve? I know there's a lot and some are pretty yucky (sqrt...)
I know it's convenient, but I made the traits non-variadic because the additional arguments are supposed to help define the property being described, as the std::is_
(nothrow_
|trivially_
)(move_
|copy_
|default_
)constructible
family of type traits does. Just me being pedantic. I can revert that part.
About the other traits improvements, I've mentioned some before. There's the problematic defaulting to void
, the traits::is_unit_v
vs detail::is_unit
because the former isn't enough, and probably some others.
I think what we should do is figure out what our v3 design philosophy should be, then the question answers itself. The current design criteria is "whatever I feel like", which is subjective and unknowable to others. I'm ok with aiming for max convenience, or for ISO suitability, but if we pick the latter I'll need your help since I'm not much of a language lawyer.
I'm not much of a language lawyer.
Luckily, this is more about following the requirements of standard library components.
The current design criteria
You've mentioned elsewhere good things, like (https://github.com/nholthaus/units/issues/196#issuecomment-433518961).
For the longest while, I've been trying to fix and improve the type traits. Since success eludes me, I'm going to push what I can. Slowly, but eventually, that should improve the situation.
UnaryTypeTrait
.