Stephen Berry

I agree in some cases to using type deduction. However, we don't want `std::string_view` parsing to be slower just because it is a `string_view`, especially when it is common for...

Definitely, but what I'm expressing is that a lot of Glaze optimizations can apply to `std::string_view` without a requirement of a null termination, but just by having a single additional...

No, because Glaze maps to C++ objects you would get an error in parsing well before you hit the null termination character. I need to explain in more detail, but...

Glaze currently does `end` iterator checks all over in parsing, so it will use the `end` iterator of your `string_view` in most cases. There are just some cases that need...

Glaze will never make logical decisions based on the extended buffer in a `string_view`, it is just that we can do SIMD optimizations if a buffer exists beyond the length...

I've opened a pull request here #1203 that adds an `is_null_terminated` option that can be set to `false` for when the input buffer is not null terminated. There's a good...

In thinking about this more I don't want to require users to set an option to handle null terminated buffers. I think it should be the default behavior to handle...

To add more thoughts for the sake of posterity: The challenge without null termination is error handling. This is particularly true because Glaze does not use exceptions. If Glaze used...

Work on contextual sentinels is now active here: #1213

After getting an implementation working for most of Glaze with contextual sentinels in #1213 I'm tempted to take the more flexible, general solution, even though it will be slower. I...