4 ms·

The difference is that the major C++14 implementations are still supported, and probably will be for as long as the concept of C++ exists. There's no `--std=py

• gjulianm 7y ago
  There is no '--std=C++14-with-arbitrary-things-from-c++20' flag either, which is what this fork does. We can discuss whether breaking backwards compatibility was bad or necessary, but creating another fork of Python that backports some features of Python 3 is just adding confusion. If their primary purpose is supporting Python 2.7 applications, they can do just fine without calling it Python.
  • comex 7y ago
    There doesn’t need to be such a flag because C++17 was fully backwards compatible with 14, with some tiny exceptions nobody cares about. Indeed, C++ has rarely made any breaking changes. A decade or so ago, GCC did cause some major ecosystem breakage, by cracking down on C++ constructs which had never been valid according to the spec but which GCC had previously allowed. When that happened, there was a flag to (at least partially) revert to the old behavior: -fpermissive.
    • Conan_Kudo 7y ago
      > There doesn’t need to be such a flag because C++17 was fully backwards compatible with 14, with some tiny exceptions nobody cares about. This literally does not parse. How do you know "nobody" cares about those exceptions?
  • wott 7y ago
    '-std=C++14' already includes a few extensions, it is not pure C++14 but a superset. And then there is '-std=gnu++14' too.