operator "" _suffix(const char* string, const std::size_t length)
The above syntax specified for user-defined string literals fails to address the case of producing complex objects at compile time based on the length of the string literal.
The following code cannot be compiled as length is a parameter. However, semantically, this code is often called in a context where the length is in fact known at compile time.
constexpr auto operator "" _test(const char* string, const std::size_t length) -> std::array<char, length> {
std::array<char, length> data{};
for (unsigned index(0); index < length; ++index) {
data[index] = string[index];
}
return data;
}
Yet, that functionality, producing complex objects at compile time from a string literal (and only a string literal), exists.
template<std::size_t length>
constexpr auto test(const char(&string)[length]) -> std::array<char, length> {
std::array<char, length> data{};
for (unsigned index(0); index < length; ++index) {
data[index] = string[index];
}
return data;
}
It seems to me to be an oversight that another (group) of user-defined string literal forms does not exist in the form
template <std::size_t length> operator "" _suffix(const char(&string)[length])
(And, potentially, and oversight that string literals were not given access to the variadic template form that user-defined integer and floating point literals have access to, and that integer and floating point literals also do not have access to this string literal syntax somehow, though that would be more difficult.)
This appears to me to be a defect in the ability to define user literals, making it impossible to define literals which produce std::array objects, or other objects with variable size determined entirely at compile time. (I used a toy example for simplicity, but I encountered this issue trying to create a literal for base64 data, and it seems it would also hinder other reasonable pursuits like creating a literal for a true compile-time string class.)
Have I missed anything?