DR1467 silently changes/breaks existing code

[j4...@dropbox.com]

Hi folks -

I’d like to start some discussion around the language change introduced by the resolution to DR1467. We found that with recent Clang (specifically that included in the Xcode 7 beta), the meaning of code invoking our open-source JSON library (https://github.com/dropbox/json11) changes silently. Before trying to come up with a workaround and figure out how to track down users of the library and communicate it to them, we're trying to figure out if this degree of semantics change was intended.

Specifically, json11 declares a class Json with a number of implicit constructors, and some type aliases (Json::array is std::vector<Json>, Json::object is std::map<std::string, Json>). The idiomatic way to build something that serializes to “[[123]]” is then:

Json j = Json::array {

  Json::array {

    123

  }

};

Json::array { 123 } (equivalent to vector<Json>{ 123 }) invokes the Json(int) implicit constructor, and then the vector(initializer_list<T>) constructor. The intent is that the outer Json::array invokes the Json(std::vector<Json>&&) implicit constructor, followed by vector(initalizer_list<T>) again. Finally, j is copy-initialized with the Json(std::vector<Json>&&) constructor.

The resolution for DR1467 substantially changes the semantics of this - because there's only one element in the init-list, the outer braces now select the vector(vector<T>&&) constructor, rather than vector(initializer_list<T>), and thus there’s only one layer of nesting.

This is pretty scary - we upgraded our compiler (to the Xcode 7 beta, though clang trunk has the same behavior) and found that the meaning of lots of our code had silently changed in a breaking way. Initially I filed a bug in Clang (https://llvm.org/bugs/show_bug.cgi?id=23812) but the issue seems rooted in the Standard, so I’m posting here as well.

So, is this a defect in the defect resolution? :) What’s the best path forward here, and on what sort of timeframe? So far, AFAIK no vendor has made a full compiler release with this new behavior - but that will change when Xcode 7 or Clang 3.7 are finalized. 

[Ville Voutilainen]

Just an ack, this has been discussed over email with some of the CWG people
approximately 5 minutes ago, I have requested that CWG reopens the issue (as
Richard said also in the bug report discussion). Stay tuned. It'll
take a bit of time
before that particular issue is looked at again in a formal setting.