https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91000
--- Comment #4 from Federico Kircheis <federico.kircheis at gmail dot com> --- > As I explained in PR 87603 comment 6, and as the patch > https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00466.html says, the old > behaviour triggers unwanted instantiations and so causes valid code to not > compile. Ok, I did not really understood that part of the discussion, I thought it was an issue in the code. The comment states explicitly that the code fails when compiling with c++2a, says nothing about c++11 and c++14 (of course I've could have tested it, my fault). > The old behaviour was not consistently implemented by other compilers so was > never portable anyway. Actually the old behaviour is implemented by GCC<9, MSVC and ICC, clang was the notable exception on my list. Testing with compiler explorer, every compiler that understands c++14 except from gcc9, clang, elcc and zapcc can compile the sample. So it seems to me that the majority got it right. There are bugs where every compiler behaves differently, so it does not seem like a big portability issue. > The C++ committee decided that the old behaviour was > not desirable, and removed it. They removed it from c++17, not from the previous standards, and it has been more by accident than by design (at least that's what I understood, also stated in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00466.html). > How many reasons do you need? Sorry, but I could not find *the* reason why the behaviour has been changed for the previous standards. The discussion starts with the c++17 change, then shows a failing sample in c++2a, and then it's fixed retroactively for every standard. Since now I've understood that PR 87603 comment 6 is also valid for previous standards I suppose that that's why you meant that the old behaviour is not consistent with the standards. (For the record: it seems that no compiler can compile the code in PR 87603 comment 6 with c++14, so the behaviour is consistent with GCC<9).
