Anders Dalvander

It would be nice to have support for `\Unnnnnnnn` though (capital U). The G clef character "𝄞" (U+1D11E) would be escaped as `\U0001D11E`.

I can't reproduce this issue anymore, any more details on versions used @stephenberry?

This was fixed in #268 for release 6.1.5.

Thank you for your report, I'm closing this issue.

The problem is that fast_float doesn't support `long double`. But the test is using `long double`: `BENCHMARK_TEMPLATE(scan_float_single_fastfloat, long double);` The error could be better though.

Regarding the `get_flags()` function. I think the following is a bit more slim, and backwards compatible; ```c++ fast_float::chars_format get_flags() const { fast_float::chars_format format_flags{}; if ((m_options & float_reader_base::allow_fixed) != 0) {...

The test compiled before because it used the !supported_float overload which in practice is an integer parser. Thank you, I'll add better errors for this.

Perhaps this then? ```c++ fast_float::chars_format get_flags() const { fast_float::chars_format format_flags{}; if ((m_options & float_reader_base::allow_fixed) != 0) { format_flags = static_cast(format_flags | fast_float::chars_format::fixed); } if ((m_options & float_reader_base::allow_scientific) != 0) {...

No. It is not any simpler or faster, the only thing it does is to mention the underlying type. `operator|(E, E)` returns an `int` (or underlying type) for unscoped enums,...

I recently changed some compile time config options into runtime config options. I believe that both worlds would be good. I would prefer if the compile time options to not...