Are there sequence points in braced initializer lists when they apply to constructors?

Question

According to the n4296 C++ standard document:

[dcl.init.list] (8.5.4.4) (pg223-224)

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list. [Note: This evaluation ordering holds regardless of the semantics of the initialization; for example, it applies when the elements of the initializer-list are interpreted as arguments of a constructor call, even though ordinarily there are no sequencing constraints on the arguments of a call. —end note ]

(emphasis mine)

The note was added here: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1030

This reads to me that the following code:

#include <iostream>

struct MyType {
  MyType(int i, int j, int k, int l)
    : sum(i + j + k + l)
  {

  }

  int sum;
};

int main()
{
  int i = 0;
  std::cout << MyType{ ++i, ++i, ++i, ++i }.sum << '\n';
}

Should print "10".

This is my reasoning:

• MyType is being initialized via a braced-init-list
• braced-init-lists are evaluated in order
• even when it is interpreted as arguments of a constructor call
• this means that it should be evaluated as MyType(1,2,3,4)

That is to say, the above code should behave exactly like this code:

#include <initializer_list>
#include <iostream>

int main()
{
  int i = 0;
  std::initializer_list<int> il{++i, ++i, ++i, ++i};
  std::cout << *il.begin() + *(il.begin() + 1) + *(il.begin() + 2) + *(il.begin() + 3) << '\n';
}

But it does not. The first example prints '16' and the second example prints '10'

Literally every compiler from every vendor that I can get my hands on prints '16', seemingly ignoring that part of the standard and not inserting sequence points.

What am I missing here?

Note: The following seem to be related to this question:

• (Optimization?) Bug regarding GCC std::thread
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253

Answer 1

The answer seems to be that yes, this is a bug in both GCC and MSVC.

This is the status of this issue:

1. There are several bugs against GCC regarding init-list rules. Most of them have gone completely unacknowledged by the GCC team. This at least implies that G++ does have bugs here because the issues have not been closed as invalid
2. I have received unofficial word from the MSVC compiler team that this is in fact a bug in their compiler and they are working internally to fix it. However, I have no external bug to point to. As of MSVC 2015 Update 3, the old behavior remains.
3. Clang, which at this point is by far the most pedantic standards-complaint compiler, implements it the way the standard seems to read.

My personal investigation, discussions with C++ experts at conferences, and unofficial answers I've received from compiler developers indicates that this is a bug in MSVC and GCC, but I'm always reluctant to answer my own questions on StackOverflow. But here we are.

Answer 2

This note is not related to evaluation order. As it was stated in one of comments, it's about order of converting actual parameters to rvalues and standard does not define such order. You should receive following warning (gcc):

17:58: warning: operation on 'i' may be undefined [-Wsequence-point]

I modified a program slightly to demonstrate how evaluation of arguments work with {} and ().

With such modification, program does not depend on order of converting lvalue to rvalue, thus does not have ambiguity which disappointed you.

#include <iostream>

struct MyType {
  MyType(int i, int j)
    : sum(i + j)
  {

  }

  int sum;
};

int main()
{
  int i = 0;
  int a,b;
  std::cout << MyType{ (a = ++i), (b = ++i) }.sum << '\n';
  std::cout << "Here clauses are evaluated in order they appear: a=" << a << ", b=" << b << std::endl;
  i = 0;
  std::cout << MyType( (a = ++i), (b = ++i) ).sum << '\n';
  std::cout << "Here order of evaluation depends on implementation: a=" << a << ", b=" << b << std::endl;
}

And the output of this program for clang and gcc:

clang:

3
Here clauses are evaluated in order they appear: a=1, b=2
3
Here order of evaluation depends on implementation: a=1, b=2

gcc:

3
Here clauses are evaluated in order they appear: a=1, b=2
3
Here order of evaluation depends on implementation: a=2, b=1

As you can see, in case of curly brackets, clauses are evaluated in order of appearance under both compilers, which corresponds to the note you provided.