This issue is just to trigger a discussion and to have a look around.

I personally think that, independent of Boost, Alpaka will provide the best user experience if there are zero pre-installed dependencies required to start if. "Zero" not accounting for the accelerator (CUDA, Fiber, TBB, ...). That does not mean we have no third-party dependencies, but we should take ones that we can auto-download in CMake and/or ship.

Pessimistic View

Boost is a heavy and unstable dependency, which is notoriously breaking with CUDA and HPC compilers such as XL. It's internal dependencies are not cleanly exposed and can change for each release. Proper CMake support is still in the making. It adds to the complexity to get started with alpaka and dependencies of header-only libs like alpaka are generally very nasty.

Besides the optional fiber backend - which is totally fine if it pulls boost - I would propose to lighten the burden of dependencies in Alpaka. The core alpaka library should therefore get rid of it.

Boost.Tests can be replaced with the stand-alone and modern Catch2 library - we use it in two projects already and it works wonderful and switching is easy:
openPMD/openPMD-api#110 (done now in #712)

Compiler detection and macros such as ignore unused (done now in #584) and class member aligns can be easily re-implemented.

Instead of mp11 #459 we could use Brigand which is also used in large projects such as vtk-m:
https://gitlab.kitware.com/vtk/vtk-m/commits/master/vtkm/internal/brigand.hpp

or other libs that are active, standalone, with good test and compiler coverage and well-maintained. Many of those also contain so-called "amalgated" single-headers (as the vtk-m link above is based on this).

Optimistic View

Should we even more deepen our boost-involvement with more pushes to native nvcc & clang -x cuda support in configs, tests, build system (legacy, new) and libraries?