Peter Dimov

At the moment all the compilers that have a `constexpr` `std::bit_cast` implement it via the intrinsic. Checking the further restrictions requires type traits, but Core can't use TypeTraits (or ``...

``` C:\boost-git\develop>dist\bin\boostdep boost/utility/addressof.hpp Inclusion report for (in module core): from asio: from bimap: from compute: from foreach: from fusion: from interprocess: from proto: from python: from range: from spirit: from...

``` C:\boost-git\develop>dist\bin\boostdep boost/utility/enable_if.hpp Inclusion report for (in module core): from accumulators: from asio: from assign: from chrono: from compute: from contract: from coroutine: from detail: from foreach: from fusion: from...

This one is easy: ``` C:\boost-git\develop>dist\bin\boostdep boost/utility/explicit_operator_bool.hpp Inclusion report for (in module core): from coroutine: from sync: ```

``` Inclusion report for (in module core): from property_tree: ```

You will lose that bet.

Yes. It doesn't look good for us when a new Boost release starts giving out deprecation warnings coming from inside Boost and not user code. So before we do that...

There are at least two reasons to prefer the current argument order. First, in the sentence "the pointer p is in the range [b, e)" the order is p, b,...

It's possible to approximate this by checking for random access and then asserting that `&*last == &*first + (last - first`). Not perfect, but better than users applying `&*` themselves,...

`&*` -> `boost::to_address`