2017-03-13 11:56 GMT+01:00 Jonathan Wakely <jwakely....@gmail.com>: > On 12 March 2017 at 13:21, Daniel Krügler <daniel.krueg...@gmail.com> wrote: >> I'm now working on >> >> http://cplusplus.github.io/LWG/lwg-defects.html#2861 >> >> The new wording state is now equivalent to basic_string_view, whose >> current implementation doesn't bother verifying the requirement, so >> this code (which as UB) currently compiles just fine: >> >> #include <string> >> #include <string_view> >> >> struct MyTraits : std::char_traits<char> >> { >> typedef unsigned char char_type; >> }; >> >> int main() >> { >> std::basic_string<char, MyTraits> my_string; >> std::basic_string_view<char, MyTraits> my_string_view; >> } >> >> So the least I could do is just - nothing. But it seems to me that we >> could protect users from doing such silly things by adding a >> static_assert to both basic_string and basic_string_view, the former >> being equivalent to >> >> #if __cplusplus >= 201103L >> static_assert(__are_same<value_type, _CharT>::value, >> "traits_type::char_type must be equal to _CharT"); >> #endif >> >> and the latter an unconditional >> >> static_assert(is_same<typename _Traits::char_type, _CharT>::value, >> "traits_type::char_type must be equal to _CharT"); >> >> Would you agree with that course of action? > > Not at this stage of gcc7 development. If the silly code compile fine > then we risk breaking working code, and we're too close to a release > to do that.
Is there a way to mark a patch suggestion for gcc8 and is so, how? > We can reconsider for gcc8 (but even then, the code has undefined > behaviour, so it would be a QoI choice whether to reject it or just > accept it, as we do for containers where Alloc::value_type doesn't > match the container's value_type). Yes, sure, purely QoI, but the fix seems to be a no-brainer. - Daniel
