Repository: ericniebler/range-v3

Issue #125: Reconsider constexpr
Created: 2015-03-29T17:42:22Z
E.g.
constexpr auto rng = view::iota(0, 10);
constexpr auto rng2 = view::iota(0) | view::take(10);
constexpr auto rng3 = rng | view::transform(square) | view::remove_if(odd);
should probably work, but that means C++14 will be a requirement. FWIW if the purpose is to prepare a C++17 library, C++14 should be a requirement anyways even tho right now that means clang > 3.6 and gcc 5.0 for the "bug-free" experience.

Duplicate issue #416: What is the future of constexpr in all this.
Created: 2016-06-27T22:02:23Z
What is the prospect of making all algorithms, views etc which can support it constexpr ?
Just to give and idea why I want to know, consider the following use case:
struct us_state {
  constexpr explicit us_static(const char *name);
};

us_state get_us_state(
  const zip_code &z  // given a zip_code
){  
  using entry = std::tuple<us_state, zip_code>;
  constexpr const entry = {
    {"california", 91602},
    {"california", 93110},
    // ...
  } table[];
  static_assert(
    ranges::v3::is_sorted_fn(table),
    "lookup table must be sorted"
  );
  auto ei = std::lower_bound(
    table, 
    [](const entry & x, const entry & y){
      return x.get<1>() < y.get<1>());
    }
  );
  // return the us state
  return ei->get<0>();
}

Closing comment (2016-06-27T22:14:07Z): Duplicate of #125 .
There is a PR with 99% of the algorithms constexpr and constexpr tests of all the algorithms (#143) in case someone wants to work on it. A couple of things were blocking:

std::invoke showed up that at least I did not understood constexpr well (and probably one of the reasons that std::invoke is not constexpr today...),
clang was, and maybe still is, the only compiler that supports that PR (maybe gcc 6.x will be able to compile range-v3 some day...),
some algorithms allocate memory. They can be made constexpr either at the expense of significantly worsening their complexity (e.g. stable_sort with an empty buffer), or they need a change in their API that allows the memory allocation to be configurable (e.g. allow stable_sort to take an allocator / buffer / some state as a parameter; this allows the user to pass a stack-allocated constexpr arena or no buffer at all, both of which work at compile-time). The clear way to proceed here is to submit a paper. Until then, those algorithms are kind of blocked.
some of the current algorithm implementations use goto. While goto is not necessary, it is not allowed in constant expressions. Rewriting them to not use goto only makes sense if that does not degrades the run-time performance. I never got to write benchmarks and profile that the versions without goto were as fast.

There is another pull-request (#134) where most of the views were constexpr (filter, transform, ...). You could use a range-based for with for (auto&& i : view::ints(0, 10) | view::transform(...) | view::filter(...)) { in a constexpr function at compile-time. With C++17 constexpr lambdas views are actually easily usable at compile-time.

this required a lot of changes to a lot of utilities back then (functional (bind...), variant, optional, ...) to make them constexpr friendly. I decided to fall back, and make first constexpr the minimum number of utilities necessary to make the algorithms constexpr (#137), and leave the views for later. Since the algorithms work never got finished, this part did not either.