Hi, one of the two experts for std::forward checking in: The replacement 
for `std::forward<T>(arg)` is simply `static_cast<T&&>(arg)` (or 
`(T&&)arg` if you prefer a  C style cast). If you care enough to know 
why: https://www.foonathan.net/2020/09/move-forward/

Note that perfect-forwarding doesn't work for the `count > 1` case, 
since you're only supposed to move variables once.

 > The new string stuff is neat, but I hit a wall trying it out: These 
fancy constructors do not reliably construct at compile time, not even 
with a constexpr qualifier in two of the three major C++ implementations.

That shouldn't happen. The compiler is required to variables with static 
storage duration at compile-time whenever the initializer can be 
evaluated at compile-time (i.e. the constructor is `constexpr`). With 
C++20, you can verify that initialization happens at compile-time using 
the `constinit` specifier on the variable. A `constinit` variable is 
either initialized at compile-time or you'll get a compiler error (but 
it doesn't change semantics, constant initialization happens regardless 
of its presence).

It has probably something to do with the fact that you're constructor 
cannot actually be executed at compile-time (but the compiler should 
have complained if you instantiated it?):

template<size N>
s8(const char (&s)[N]) : data{(u8 *)s}, len{N-1} {}

Assuming `u8` is `unsigned char`, the `(u8*)s` cast is not constexpr 
since you're not only casting away const, you're also doing a C++ 
reinterpret_cast. That isn't allowed at compile-time since the 
compile-time representation of a value can differ from the runtime 
representation, so reinterpreting can yield different results.

Thanks for the information, Jonathan. This was very helpful! The three 
"problematic for multiple reasons" items in your article are spot on, 
capturing my own feelings.

> simply `static_cast<T&&>(arg)` (or `(T&&)arg` ...)

Ha, it's so simple. I tried throwing everything at it I might care about, 
and it worked. Your article gives me confidence it's correct, too. Part of 
my confusion was stuff like this Stack Overflow discussion, about why the 
static cast isn't quite right, the need for remove_reference, etc.

https://stackoverflow.com/questions/27501400/the-implementation-of-stdforward

So I gave up on trying to work it out myself. I should have just tried it.

> [...] a C++ reinterpret_cast. That isn't allowed at compile-time [...]

Ah, I'm pretty sure that's it. In that case it seems I won't be able to 
accomplish what I want using a constructor.

On 15.04.24 04:20, Christopher Wellons wrote:
> Thanks for the information, Jonathan. This was very helpful! The three 
> "problematic for multiple reasons" items in your article are spot on, 
> capturing my own feelings.

Some C++ programmers care about compile-time bloat as well.

(But it's just so my excessive template use is less noticable... :D)

> 
>> [...] a C++ reinterpret_cast. That isn't allowed at compile-time [...]
> 
> Ah, I'm pretty sure that's it. In that case it seems I won't be able to 
> accomplish what I want using a constructor.

Yes, not with a constructor, but the dark side of C++ is a pathway to 
many abilities some considered to be unnatural: 
https://godbolt.org/z/56dehMcKj

Depending on your compiler/linker settings you might also make the 
`string_literal` variable template as inline and then the linker is 
required to merge instantiations across translation units. As a bonus, 
you are then guaranteed that `==` works for string literals.