[stmt.expand] Does the for loop that calculates N need to `void`-cast the return value of incrementing the iterator?

[hewillk]

From [stmt.expand]:

where N is the result of evaluating the expression

[] consteval {
  std::ptrdiff_t result = 0;
  for (auto i = begin; i != end; ++i, ++result);
  return result;                                // distance from begin to end
}()

Do we need to do a void casting here to comply with the standard's awareness of operator,?

[] consteval {
  std::ptrdiff_t result = 0;
  for (auto i = begin; i != end; ++i, (void)++result);
  return result;                                // distance from begin to end
}()

If so, is this LWG or CWG, or is this editorial (which I strongly doubt)?

[jensmaurer]

If at all, that's CWG.

However, absent further rationale, anyone overloading operator, on the return value of "++i" (probably an iterator type) will just get what they deserve. The core language isn't intrinsically required to protect its users from self-inflicted stupidity.

Maybe that's worth an NB comment, for EWG to decide how much we want to protect against user stupidity. Although the code in question was produced during CWG review.

[hewillk]

NB comment is probably a more appropriate choice.
Though it may be necessary for someone else to submit this.

[Eisenwave]

If this was about over-arching operator,-safety design strategy, it should be an NB comment, but I think it's fairly clear that this particular lambda is just supposed to increment the iterator while also counting in result how many iterations it took.

The design intent seems clear to me. This construct is not some sort of customization point which makes sense to alter with operator, overloads. NB comment seems more complicated than this issue is; this should be a CWG issue in my opinion.

Another way to write it (which may be clearer) would be:

[] consteval {
  std::ptrdiff_t result = 0;
  for (auto i = begin; i != end; ++i) { ++result; }
  return result;
}()

[jensmaurer]

@Eisenwave , your line of reasoning also seems to suggest we should somehow protect against "++" on iterators doing something stupid, too, but we don't: We just assume the usual semantics when rewriting the expansion statement. For example, we're not applying library-level syntax constraints on the iterators involved, but we could.

The question to EWG is how much effort we want to invest into protecting against hostile user types in such reasonably complicated rewrite scenarios.

[Eisenwave]

I agree to an extent, but we cannot avoid use of ++ here, or avoid begin()/begin(...) in range-for, or avoid get<N> in structured bindings, etc. I am fine with relying in core wording that these do "the right thing" because we need them.

Using the comma operator between ++i and ++result is entirely unnecessary though, and as a general policy, I think we should avoid using more expressions or relying on the validity/semantics of expressions, unless it's actually needed. That seems to be a desirable language design policy, and extends beyond just

protecting against hostile user types