https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78156
Daniel Krügler <daniel.kruegler at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel.kruegler@googlemail.
| |com
--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
Strictly speaking, the provided example doesn't reveal a defect in the existing
implementation.
Changing char_traits::length to be constexpr would be non-conforming (at least
an extension), albeit one could argue that an implementation *could* decide to
implement std::string_view::string_view(const char*) [but only this specific
constructor] in a way where a built-in would be used (very similar as you
describe), whose semantics would be equivalent to calling
std::char_traits<char>::length, since the existing wording does only impose
post-conditions and requirements imposed on user-input, it doesn't require
specifically the usage of std::char_traits<char>::length (given the specific
type char). For user-defined traits and character types there would be no
alternative, though. But all this is just QoI and no requirement.
As a user you could provide your own hand-rolled fully constexpr character
trait class and instantiate basic_string_view with that one or you could write
a constexpr helper function that uses a constexpr length function and returns a
std::string_view object by internally calling the
std::string_view::string_view(const char*, size_type) constructor instead.
Note that there exists an open library evolution issue related to that:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2232
