Closed JDuffeyBQ closed 1 month ago
Yeah I was waiting until this gets merged to do any improvements to keep this PR minimal.
For nonstd::span
it actually detects if std::span
is available and typedefs it if it is. So it will be using it for the compile but to minimize our dependencies we can remove it in the future.
The issue with std::string_view
is that it is not guaranteed to be null terminated since it can represent an arbitrary slice of a string. Our StringLiteral
is a null terminated string basically a std::string_view
-like wrapper around a true string literal. This is useful for third party APIs that take char*
where they assume it is null terminated.
Some notes: Since this PR is mainly about getting compatibility up, I don't think these are necessary here I just wanted to mention them, since they are related to the topic of the PR.
nonstd::span
tostd::span
since it is included in c++20enable_if
statements in the template declarations should be reviewed to see if they can be changed toconcept
declarations for readability and more centralized type gating (such as in the types.hpp file)concept
to reduce the compilation scope of the template heavy filesBasicStringLiteral
does in the current code base, theStringLiteral
alias can be switched to astd::string_view