[stmt.expand] Expansion statements vs. define_static_array

[jakubjelinek]

Full name of submitter (unless configured in github; will be published with the issue): Jakub Jelinek

Reference (section label): [stmt.expand]

Link to reflector thread (if any):

Issue description:
I've tried to use iterating expansion statement on define_static_array, but it doesn't work.

#ifdef USE_EXPANSION_STMT_AND_DEFINE_STATIC_ARRAY
#include <meta>
#endif
#include <span>

constexpr int arr1[3] = { 1, 2, 3 };
consteval std::span <const int> foo () { return std::span <const int> (arr1); }

void
bar ()
{
#ifdef USE_EXPANSION_STMT_AND_DEFINE_STATIC_ARRAY
  template for (constexpr auto m : std::meta::define_static_array (std::vector { 1, 2, 3 }))
    ;
#elifdef USE_EXPANSION_STMT
  template for (constexpr auto m : foo ())
    ;
#else
  static constexpr auto &&range = foo ();
  static constexpr auto begin = range.begin ();
  static constexpr auto end = range.end ();
  static constexpr auto N = [] consteval {
    std::ptrdiff_t result = 0;
    for (auto i = begin ; i != end ; ++i) ++result;
    return result;
  }();
  static_assert (N == 3);
  {
    static constexpr auto iter = begin + decltype(begin - begin){std::ptrdiff_t(0)};
    constexpr auto m = *iter;
  }
  {
    static constexpr auto iter = begin + decltype(begin - begin){std::ptrdiff_t(1)};
    constexpr auto m = *iter;
  }
  {
    static constexpr auto iter = begin + decltype(begin - begin){std::ptrdiff_t(2)};
    constexpr auto m = *iter;
  }
#endif
}

This test includes what I'm trying to make work, something that does the same thing and fails the same way without reflection and finally attempt to desugarize the expansion statement (note, partly pre-CWG3044 as neither GCC nor clang implements full P2686R4 paper and so I can't remove the static keywords just yet.
Anyway, all 3 versions including the desugarized one fail, the desugarized one with both GCC and clang.
The problem is that type of range is deduced as std::span <const int> && and so it refers to non-const lifetime extended temporary and constant evaluation of the rest doesn't work because of that.
For GCC this can be worked around with using (const std::span <const int>) define_static_array (std::vector { 1, 2, 3 }) instead of define_static_array (std::vector { 1, 2, 3 }) or (const std::span <const int>) foo () instead of foo (), but I don't think that is meant to be what users should use when using expansion statements with define_static_array.
For clang the desugarized version compiles if static constexpr auto &&range = foo (); is changed to static constexpr const auto &&range = foo ();, for GCC I think due to a bug doesn't.

Suggested resolution:
So, I wonder if https://eel.is/c++draft/stmt.expand#5.2 shouldn't be changed
constexpr const auto&& range = expansion-initializer;

@jensmaurer @katzdm

[jakubjelinek]

Or perhaps to
constexpr const auto&& range = expansion-initializer;

[timsong-cpp]

@brevzin and I just talked about this:

• to support prvalue spans we need to add const for prvalues
• to support the unrolling case (iterating over an lvalue array or array) we want to avoid unnecessarily adding const to lvalues
• for xvalues...don't care too much but probably same treatment as lvalue.

which would suggest...

constexpr decltype(auto) range = (expansion-initializer);

(yes, with the extra parens)

[brevzin]

I think that approach should cover all cases except for one (which is already not covered):

/* not constexpr */ auto get() -> std::array<T, N>; 

auto f() -> void {
    template for (T v : get()) ;
}

The range declaration fails (in any formulation). If we could allow ourselves to fall through to the tuple case, the tuple case would work fine here. I think it's important to get this case working too, since std::array is even tuple-like so all of the other algorithms work with it.

---

Although the downside of supporting the above case is:

/* not constexpr */ auto get_array() -> std::array<T, N>; 
/* not constexpr */ auto get_subrange() -> std::ranges::subrange<I, S>;

auto f() -> void {
    // we want this to behave like a tuple (and work)
    template for (auto&& v : get_array()) ;

    // we want this to NOT behave like a tuple (and fail)
    template for (auto&& v : get_subrange()) ;
}

Which maybe suggests wanting different syntax for the tuple and range cases.

[jakubjelinek]

I've tried to implement the
static constexpr decltype(auto)auto&& range = (expansion-initializer);
change in GCC and while it fixed the

// C++26 P1306R5 - Expansion statements
// { dg-do run { target c++23 } }
// { dg-options "" }

#include <span>

constexpr int arr[3] = { 1, 2, 3 };
consteval std::span <const int> foo () { return std::span <const int> (arr); }

int
main ()
{
  int r = 0;
  template for (constexpr auto m : foo ())	// { dg-warning "'template for' only available with" "" { target c++23_down } }
    r += m;
  if (r != 6)
    __builtin_abort ();
}

testcase it broke quite a few of our existing testcases.
E.g.

// C++26 P1306R5 - Expansion statements
// { dg-do run { target c++14 } }
// { dg-options "" }

struct A
{
  int x;
  constexpr explicit A (int v) : x(v) {}
  constexpr A &operator ++ () { ++x; return *this; }
  constexpr int operator * () const { return x; }
  constexpr bool operator != (const A &o) const { return x != o.x; }
  constexpr A operator + (int o) const { A r (x + o); return r; }
  constexpr int operator - (const A &o) const { return x - o.x; }
};

namespace N
{
  struct B { constexpr B () {} };
  constexpr A begin (B &) { return A (0); }
  constexpr A end (B &) { return A (6); }
}

int
foo ()
{
  int r = 0;
  template for (auto i : N::B {})				// { dg-warning "'template for' only available with" "" { target c++23_down } }
    r += i;
  return r;
}

now fails with
expansion-stmt1.C: In function ‘int foo()’:
expansion-stmt1.C:28:11: error: binding reference of type ‘N::B&’ to ‘const N::B’ discards qualifiers
28 | r += i;
| ^
expansion-stmt1.C:19:22: note: initializing argument 1 of ‘constexpr A N::begin(B&)’
19 | constexpr A begin (B &) { return A (0); }
| ^~~

Changing

  constexpr A begin (B &) { return A (0); }
  constexpr A end (B &) { return A (6); }

to

  constexpr A begin (const B &) { return A (0); }
  constexpr A end (const B &) { return A (6); }

fixes that. Just wanted to mention it that it has this consequence, we can certainly adjust the testsuite for that.

[timsong-cpp]

I don't think you can simultaneously support that and the span case without something like a trial constant evaluation on begin...

[jakubjelinek]

If it is unlikely to happen in real-world C++, not a problem. I just wanted some very simple iterator + range in the tests without uses of any library headers.

[jensmaurer]

@jakubjelinek , I think you found an interesting case for expansion statements, mostly unrelated to define_static_array.

@brevzin @katzdm , do you want to go with the decltype(auto) approach (causing Jakub's existing testcases fail), or should we do a trial constant-evaluation of begin(E) and end(E) for differentiation?

And is that something for EWG to have an opinion on?

[brevzin]

I think the decltype(auto) approach is correct. It requires adding const in Jakub's example, but I think that's totally fine. For that matter, we could change stmt.ranged for consistency too right, not sure it's even observable?

should we do a trial constant-evaluation of begin(E) and end(E) for differentiation?

I don't think a trial constant-evaluation is the right approach. I think the more interesting approach is actually what we had in the prose in P1306 and I somehow lost in the wording for the iterable case (but preserved in the destructuring case): the range is declared constexpr if and only if the loop variable is declared constexpr. That is, Jakub's example

int
foo ()
{
  int r = 0;
  template for (auto i : N::B {})				// { dg-warning "'template for' only available with" "" { target c++23_down } }
    r += i;
  return r;
}

Would simply have a non-constexpr (and thus non-const) range, instead of an unconditionally constexpr one. That would require a slightly different formulation of calculating N, but this is valid C++26:

decltype(auto) rng = (N::B{});
constexpr auto N = [&]() consteval {
  int result = 0;
  auto b = begin(rng);
  auto e = end(rng);
  for (; b != e; ++b) ++result;
  return result;
}();
static_assert(N == 6);

This would make it so that you can expand over a non-constexpr std::array, which you otherwise cannot do.

Basically if we consider the cross of:

		range
		constexpr	non-constexpr
declaration	constexpr	typical reflection use-case	B???
	non-constexpr	A???	force-unrolling runtime array

I'm not sure if there's a strong motivation for a constexpr range with non-constexpr declaration (A), and it seems pretty rarely possible to even have a non-constexpr range with a constexpr declaration (B).