4 ms·

> We've already been improving C++'s safety and ergonomics with every ISO C++ release, but they have been "10%" improvements. We haven't been able to do a "10x"

> We've already been improving C++'s safety and ergonomics with every ISO C++ release, but they have been "10%" improvements. We haven't been able to do a "10x" improvement primarily because we have to keep 100% syntax backward compatibility. You really don't. The vast majority of projects will never change the language version they use. Simple projects are simple to fix. Remaining large projects have enough resources and expertise to do changes across their entire code base - Chromium has recently changed more than 15000 instances (in over 8000 files) of using raw pointers to using raw_ptr instead in a single pull request [0]. How? They wrote a Clang based tool which did it automatically [1]. [0] https://chromium-review.googlesource.com/c/chromium/src/+/3305132 https://chromium-review.googlesource.com/c/chromium/src/+/33... [1] https://source.chromium.org/chromium/chromium/src/+/main:tools/clang/rewrite_raw_ptr_fields/RewriteRawPtrFields.cpp https://source.chromium.org/chromium/chromium/src/+/main:too...

tusharsadhwani 4y ago
Projects can't keep using an old compilers because of security patches though. At some point, the old versions are too old to keep the security up to date. A more common example, what if a library that you use stops supporting the old version, and the latest compatible release of the library has a security vulnerability.
- frankjr 4y ago
  > Projects can't keep using an old compilers because of security patches though. At some point, the old versions are too old to keep the security up to date. I'm talking about using the same language version (standard), not compiler version - e.g. the latest Clang still supports the C++98 ISO version. > A more common example, what if a library that you use stops supporting the old version, and the latest compatible release of the library has a security vulnerability. You backport the fix or the change library. Nobody said it's easy but your project should not hold the entire language hostage.
detaro 4y ago
That doesn't match my professional experience: Many code bases iteratively move forward through language versions. They do vary in how intensely they drive this, which can lead to vast differences across different areas of the code, but that is not necessarily bad, but would be an issue with hard breaks.
lostdog 4y ago
There was a years-long conniption over the Python 2 to 3 migration. I also believe that it's ok for a language to break backwards compatibility once every 40 years, but I completely understand why so many language designers are afraid to.
tsimionescu 4y ago
There is no known example of a language successfully doing (significant) backward-incompatible changes. The few languages that tried usually got caught in a decade+ long mire (Python3). Now, many languages, including C++, have gotten away with smaller backwards-incompatible changes (e.g. C++ 17 removed dynamic exception specifications from the language entirely - getting away with it because it was an almost entirely unused non-feature). Edit: removed some reference to PHP6 where I had a wrong recollection.

tusharsadhwani 4y ago

Projects can't keep using an old compilers because of security patches though. At some point, the old versions are too old to keep the security up to date. A more common example, what if a library that you use stops supporting the old version, and the latest compatible release of the library has a security vulnerability.

frankjr 4y ago
> Projects can't keep using an old compilers because of security patches though. At some point, the old versions are too old to keep the security up to date. I'm talking about using the same language version (standard), not compiler version - e.g. the latest Clang still supports the C++98 ISO version. > A more common example, what if a library that you use stops supporting the old version, and the latest compatible release of the library has a security vulnerability. You backport the fix or the change library. Nobody said it's easy but your project should not hold the entire language hostage.

detaro 4y ago

That doesn't match my professional experience: Many code bases iteratively move forward through language versions. They do vary in how intensely they drive this, which can lead to vast differences across different areas of the code, but that is not necessarily bad, but would be an issue with hard breaks.

lostdog 4y ago

There was a years-long conniption over the Python 2 to 3 migration. I also believe that it's ok for a language to break backwards compatibility once every 40 years, but I completely understand why so many language designers are afraid to.

tsimionescu 4y ago

There is no known example of a language successfully doing (significant) backward-incompatible changes. The few languages that tried usually got caught in a decade+ long mire (Python3). Now, many languages, including C++, have gotten away with smaller backwards-incompatible changes (e.g. C++ 17 removed dynamic exception specifications from the language entirely - getting away with it because it was an almost entirely unused non-feature). Edit: removed some reference to PHP6 where I had a wrong recollection.