<string_view>: Problem: static_assert() in a template or type

[DBJDBJ]

My comment on MS STL admirers issue

static_assert() inside a template controls only the instatiation of the type definition. Not the mechanism of type definition.

template <typename T>
struct not_a_vector {
  static_assert(std::is_trivially_copyable_v<T>,
                "\n\nnot_a_vector<>T -- can handle only trivially "
                "copiable types!\n\n");
} ;

// no warning even if -Wall is used
   using should_not_compile_but_it_does
               = not_a_vector<std::string>  ;

Consider instead imposing the type definition requirement.

template <typename T,
std::enable_if_t< std::is_trivially_copyable_v<T>, int > = 0
>
class better_not_a_vector {
} ;

using should_not_compile_and_it_does_not =
               better_not_a_vector<std::string>;

using should_compile_and_it_does =
               better_not_a_vector<bool>;

better_not_a_vector<T> can not be promoted to type definition if the author's requirement is not satisfied.

Gobolt here

[StephanTLavavej]

While other libraries can reject invalid template arguments as early as possible using the technique you mentioned, in the Standard Library we're constrained by the Standard's very strict requirements. In particular, forming types like tuple<void> or basic_string_view<void ***> is completely valid as far as the Standard is concerned - only when the classes are instantiated (e.g. attempting to create objects of such types) can the requirements on types be enforced.

[DBJDBJ]

Well here is the idea for the c++23 paper. IMHO that is a loophole. The user is allowed to create an illegal type. Until some other user in the future tries to make use of it when it bombs.

Thanks for your reply...

[DBJDBJ]

@StephanTLavavej of course one should not engage in anything after a long day of coding :)

Thus I forgot the obvious and simple C++20 solution

template< typename T, std::size_t k>
#if __cplusplus >= 202002L
    // C++20 (and later) code
requires // requires-clause (ad-hoc constraint)
(k >= 4 && k <= 30) 
#endif
class constrained_hyper_log_log ;

using constrained_derived_type = constrained_hyper_log_log<bool, 13> ;

I might assume the standard is not constraining you not to use constraints.

[DBJDBJ]

I am becoming a pest by now :)

Godbolt

[mnatsuhara]

If the Standard doesn't depict a class template as being constrained, then we are not required to add such constraints to user-visible types. Even if we theoretically were permitted by the Standard to do this, we would not be comfortable making this change to existing types and risking significant disruption to existing code for this small benefit. Thanks for bringing this to our attention, but we don't plan on making any changes regarding this issue.

[DBJDBJ]

Thanks for the reply. I understand and condone it.

But being a wanderer I am wandering. How would MISRA or another less known safe coding for mission-critical apps standards, react to this?

Until now I was recommending MS STL because of its "no exceptions" aka "/kernel" switch mode implementation. Using SEH and all that foundational stuff. In that mode, MS STL selection is a no-brainer compared to EASTL and similar "magical" STL implementations. Actually implementing just a subset of std::.

But now one has to "manage around" this not-a-issue.

End of discussion, many thanks ...