[Bug c++/71502] Fold expression unpacks (I < ...) the wrong way

["horridminded at mailinator dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502

Sleep tight pupper <horridminded at mailinator dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |horridminded at mailinator dot com

--- Comment #3 from Sleep tight pupper <horridminded at mailinator dot com> ---
This is not a bug. 

See this discussion:
https://groups.google.com/a/isocpp.org/forum/#!msg/std-discussion/Sxbm2CEpMv4/CbfJtKGLEAkJ
and explanation by the author of the proposal, Richard Smith.

> > In N4295 [1], which was actually voted into the standard,

> > (... op e) is a

> >> *unary left fold;*(e op ...) is a *unary right fold;*
> > In N4191[2], however,

> >> (e op ...) is called a *left fold*.
> >> (... op e) is called a *right fold*.

> > Why the 180-degree turn?

> The form in the original paper was simply a typo. Here are some reasons why
> the definition that was voted into the standard is the correct one:

> 1)  In the standard's formulation, (e op ...) has subexpressions of the
> form (e_i op <stuff>). It does not have subexpressions of the form (<stuff>
> op e_i). This is consistent with all other pack expansions, where the
> expansion comprises repeated instances of the pattern.

> 2) (e op ... op eN), where eN is a non-pack, must have eN as the innermost
> operand in order to be useful -- that is, it must be (e1 op (e2 op (e3 op
> (... op eN)...))), not (...(((e1 op e2) op e3) op ...) op eN) -- and vice
> versa for (e0 op ... op e). This allows, for instance, (string() + ... +
> things) and (std::cout << ... << things) to work. For consistency, (e op
> ...) must also be (e1 op (e2 op (...))).