Peter Dimov

This is https://github.com/boostorg/url/issues/779 and https://github.com/bfgroup/b2/issues/352, which is fixed with https://github.com/bfgroup/b2/commit/2474be56b42e191bbc0706d46177703b24a7e7c3.

If invalid UTF-16 is allowed, unpaired surrogates would probably need to be UTF-8 encoded, and the result will be [WTF-8](https://simonsapin.github.io/wtf-8/).

I think that this deserves a different option, `allow_invalid_utf16`. The input isn't invalid UTF-8, so it's not the same thing.

You can still use Describe if you declare an intermediate struct holding the parameters.

On second thought, isn't ``` MyClass{json.at("superint1").to(), json.at("superint2").to(), json.at("superbool").to(), json.at("superstring").to(), json.at("supervectorofint").to()} ``` possible to write today as ``` MyClass{ value_to(json.at("superint1")), value_to(json.at("superint2")), value_to(json.at("superbool")), value_to(json.at("superstring")), value_to(json.at("supervectorofint")) } ``` ?

I suppose this is again caused by `BOOST_NO_CXX11_HDR_MUTEX` being defined by Boost.Config for this platform, but I've no idea why that is. Is libstdc++ compiled as single-threaded?

In that case, the solution is to define the macro BOOST_SYSTEM_DISABLE_THREADS.

Proof of concept: https://gist.github.com/pdimov/d5646e1887be00d7991b199892adb9c1

It might be better to use the mulx primitive, which xors the low and high part of the multiplication, instead of just taking the high part. This - to the...

I can't think of any downside to making `embed-manifest-via=linker` the default unconditionally across the board, so that the manifest tool is no longer needed.