Date: Fri, 20 Aug 2021 19:51:28 +0200
Many thanks to all on replies. Let me try and clarify.
I was specifically told by one of the STL authors, the standard allows for
illegal types to be defined from std:: templates.
Examples given were:
using bad_type_1 = tuple<void>; using bad_type_2 = basic_string_view<void
***>;
I also understood the standard is barring STL authors to constrain the
types and use (for example) enable_if<> for C++ < 20 or requires for C++ >=
20 , thus they are using static_assert().
AFAIK static_assert() is instantiation constraint not type definition
constraint.
This is not a rant or similar, I am just looking for a confirmation.
Kind regards
On Fri, 20 Aug 2021 at 14:05, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> On Fri, 20 Aug 2021 at 11:43, 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?
>
> > 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.\"");
>
> Well, string_view needs to work in C++17 mode, so rather than doing
> that both with a constraint and with a static_assert,
> an implementation vendor can easily choose to use just a
> static_assert. And as others have hinted, a static_assert allows
> the library writer to decide the text of the diagnostic, which can be
> beneficial.
>
I was specifically told by one of the STL authors, the standard allows for
illegal types to be defined from std:: templates.
Examples given were:
using bad_type_1 = tuple<void>; using bad_type_2 = basic_string_view<void
***>;
I also understood the standard is barring STL authors to constrain the
types and use (for example) enable_if<> for C++ < 20 or requires for C++ >=
20 , thus they are using static_assert().
AFAIK static_assert() is instantiation constraint not type definition
constraint.
This is not a rant or similar, I am just looking for a confirmation.
Kind regards
On Fri, 20 Aug 2021 at 14:05, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> On Fri, 20 Aug 2021 at 11:43, 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?
>
> > 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.\"");
>
> Well, string_view needs to work in C++17 mode, so rather than doing
> that both with a constraint and with a static_assert,
> an implementation vendor can easily choose to use just a
> static_assert. And as others have hinted, a static_assert allows
> the library writer to decide the text of the diagnostic, which can be
> beneficial.
>
Received on 2021-08-20 12:51:46