Hi,

P2041 proposes deleting primary class templates for a similar effect.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2041r1.html

Cheers,
Lénárd


-------- Original Message --------
From: DBJ <dbj_at_[hidden]>
Sent: August 22, 2021 6:40:19 AM GMT+01:00
To: STD PROPOSALS <std-proposals_at_[hidden]>
Cc: "Lénárd Szolnoki" <cpp_at_[hidden]>
Subject: Re: [std-proposals] Are constrained type barred from std:: implementations?

Lenard makes sense :)

I might add.

In a large project, multi team, situations allowing illegal template types
definitions is a foot gun with a timer. Also well hidden.

Thank you all

On Fri, 20 Aug 2021, 22:52 Lénárd Szolnoki via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Fri, 20 Aug 2021 10:41:54 +0200
> DBJ via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> > I can see (for example) static_assert being used in basic_stringview
> > to constrain the instantiation of it. Not the type definition.
> >
> > Thus I am wondering what was/is wrong with using C++20 require, for
> > example?
> >
> > I was told standard specifically allows for wrong types to be
> > defined; like eg tuple<void> or basic_stringview<void ***> ...
> >
> > Is the following synopsis thus not following the standard?
> >
> > #include <string>
> > #include <type_traits>
> >
> > namespace {
> > using namespace std;
> >
> > template <class _Elem, class _Traits>
> > #if __cplusplus >= 202002L
> > // C++20 (and later) code
> > requires // requires-clause (ad-hoc constraint)
> > is_same_v<_Elem, typename _Traits::char_type> &&
> > (!is_array_v<_Elem>)&&is_trivial_v<_Elem>&&
> > is_standard_layout_v<_Elem> #endif
> > class basic_string_view { // wrapper for any kind of contiguous
> > character
> > // buffer
> > public:
> > #if __cplusplus < 202002L
> > // apparently standard was/is barring std:: types to be constrained?
> > // ditto this is instantiation constraint
> > // as present in MS STL today
> > static_assert(is_same_v<_Elem, typename _Traits::char_type>,
> > "Bad char_traits for basic_string_view; "
> > "N4659 24.4.2 [string.view.template]/1 \"the type "
> > "traits::char_type shall name the same type as
> > charT.\"");
> >
> > static_assert(!is_array_v<_Elem> && is_trivial_v<_Elem> &&
> > is_standard_layout_v<_Elem>,
> > "The character type of basic_string_view must be a
> > non-array "
> > "trivial standard-layout type. See N4861 "
> > "[strings.general]/1.");
> > #endif
> > };
> >
> > using ok_sv = basic_string_view<char, std::char_traits<char> >;
> >
> > } // namespace
> >
> > *https://godbolt.org/z/44cWrqqcs <https://godbolt.org/z/44cWrqqcs>*
>
> There is an observable difference between constraining the primary class
> template and static_assert within the body of the class template
> definition, that is in the latter case the types `function<int>*`,
> `basic_string_view<void***>*`, ... can be formed or in general these
> types can be used as incomplete types so that the corresponding class
> template specializations are not instantiated.
>
> https://godbolt.org/z/xrfY9j64e
>
> In the standard the synopsis is not constrained, and I'm not sure that
> implementers are allowed to add that to primary class templates, even
> though it would probably make sense.
>
> Cheers,
> Lénárd
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>