On what base fold expression of a parameter pack consisting of a single element is transformed into unparenthesized expression

Question

Consider an example:

#include <type_traits>

template <class... Ts>
decltype (auto) foo(Ts... ts) {
      return (ts->x + ...);
}

struct X {
    int x;
};

int main() {
    X x1{1};
    static_assert(std::is_reference_v<decltype(foo(&x1))>);
}

[live demo]

decltype(auto) deduced from parenthesized lvalue should according to [cl.type.simple]/4.4 be deduced to lvalue reference. E.g.:

decltype(auto) foo(X *x) { // type of result == int&
    return (x->x);
}

But the snipped triggers static_assert. Even if we compose expression into additional parentheses, e.g.:

return ((ts->x + ...));

It doesn't change the effect.

Is there a point in the standard that prevents deduction of a fold-expression of a single element into the lvalue reference?

---

Edit

As a great point of Johannes Schaub - litb clang actually does interpret the double-parens-version of the code as parenthesized lvalue and deduce lvalue reference. I'd interpret it as a gcc bug in this case. The version with single-parens-version is however still under the question. What puzzles me is that the version must be transformed into a parenthesized code at least in case of more than one element - to fulfil operator precedence. E.g.:

(x + ...)*4 -> (x1 + x2)*4

What is the reason of the inconsistency?

Answer 1

If you want a reference to be returned in the single parameter case, you'll need an extra set of parenthesis^* so that the parameter pack expansion expands references:

template <class... Ts>
decltype (auto) foo(Ts... ts) {
      return ((ts->x) + ...);
}

Unfortunately in the scenario of multiple arguments being passed, the result is still the summation of integers, which returns an rvalue, so your static assertion will fail then.

---

Why doesn't ((ts->x + ...)) evaluate to a reference?

Because the fold expression will return an expiring int and then wrapping that int in another level of parentheses is still an int. When we use the inner parentheses ((ts->x) + ...)) the fold expression for a single argument returns int&. It does for clang 6.0.0 but not gcc 8.0.0, so I'm not sure.

^{*The fold expression's parentheses (the parentheses involved in (ts->x + ...)) are required as part of the fold expression; saying ts->x + ... alone is ill-formed.}

Answer 2

After a small investigation it turns out that standard does not provide any explicit guarantees on the parenthesizeness of an expression produced from fold expression [temp.variadic]/9 (emphasis mine):

The instantiation of a fold-expression produces:

• ((E1 op E2) op ⋯) op EN for a unary left fold,
• E1 op (⋯ op (EN−1 op EN)) for a unary right fold,
• (((E op E1) op E2) op ⋯) op EN for a binary left fold, and
• E1 op (⋯ op (EN−1 op (EN op E))) for a binary right fold.

In each case, op is the fold-operator, N is the number of elements in the pack expansion parameters, and each Ei is generated by instantiating the pattern and replacing each pack expansion parameter with its ith element. For a binary fold-expression, E is generated by instantiating the cast-expression that did not contain an unexpanded parameter pack.

Example:

template<typename ...Args>
  bool all(Args ...args) { return (... && args); }

bool b = all(true, true, true, false);

Within the instantiation of all, the returned expression expands to ((true && true) && true) && false, which evaluates to false. — end example

If N is zero for a unary fold-expression, the value of the expression is shown in Table 14; if the operator is not listed in Table 14, the instantiation is ill-formed.

This would suggest that there is no guarantees about the parenthesize even when of the fold expression operator would affect the change of the operators precedence of the produced expression which seems to be a standard defect to me. E.g. (ts + ...)*4 should be expanded to ts1 + ts2*4 and not (ts1 + ts2)*4 when literally apply the rule in the example from standard.

Nevertheless as the single element parameter pack isn't considered in the fold expression production rule it is underspecified what should parameter pack produce in this case and hence both parenthesized version as well as unparenthesized one conform the standard.