Open msimberg opened 3 years ago
What about the hpx::apply
<--> std::apply
semantic mismatch? Should we start deprecating hpx::apply
for some other name (hpx::fire_n_forget
/hpx::post
?) so we can substitute our hpx::util::invoke_fused
with std::apply
without causing undue confusion?
- Replace various utilities with
std
counterparts (e.g. hpx::invoke -> std::invoke)
std::invoke
implementations are considerably heavier at build time. It makes sense to replace hpx::invoke
in examples and other user facing bits. In implementation code HPX_INVOKE
should be used instead, to additionally reduce the stack noise in debug builds.
What about the
hpx::apply
<-->std::apply
semantic mismatch? Should we start deprecatinghpx::apply
for some other name (hpx::fire_n_forget
/hpx::post
?) so we can substitute ourhpx::util::invoke_fused
withstd::apply
without causing undue confusion?
Yes, I think we'll have to start deprecating it. I'm not sure what would be the best name for it. Another alternative would be to redirect users to hpx::execution::experimental::execute
as an alternative, but it may be too early. That would require a customization for executors (just forward to post
) and execute
would have to become variadic.
std::invoke
implementations are considerably heavier at build time. It makes sense to replacehpx::invoke
in examples and other user facing bits. In implementation codeHPX_INVOKE
should be used instead, to additionally reduce the stack noise in debug builds.
Thanks, that makes sense. I suppose if that's the case we could at least putting invoke and friends in detail
.
Now that we require C++17 we can start using C++17 features more liberally without having to worry about fallbacks for older standards. Below is a grab bag of things we could start changing (please feel free to add to the list, or even better simply make the change if there's something missing). Keep in mind that we don't need to change every instance possible in one go, so don't be afraid to just make a local change while you're working on some piece of code (as we do right now with e.g.
typedef
tousing
). Small steps are better than no steps.HPX_INLINE_CONSTEXPR_VARIABLE
macro withinline constexpr
if constexpr
for dispatching where appropriate (e.g.std::true/false_type
overloads: https://github.com/STEllAR-GROUP/hpx/blob/03309bea58bcc18aff2864900c77e31116158b1b/libs/parallelism/futures/include/hpx/futures/future.hpp#L51-L84) (#6083)std
counterparts (e.g.always_void
->void_t
) (#6082)std
counterparts (e.g.hpx::invoke
->std::invoke
? @K-ballo I suspect you know best which ones are actually reasonable to change and for which ones we actually would want to keep our own implementation)hpx::invoke_fused
tohpx::apply
[[nodiscard]]
) (#5818)static_assert
s that don't have a meaningful message (#6092)_t
and_v
variants of various type traits where appropriate, nested namespace definitions (e.g.namespace hpx::execution::experimental { }
)std::string_view
instead ofboost::string_ref
(#6093)