3 ms·

I work at smaller scale c++ than google and I found most of their proposals reasonable but undoable for practical reasons rather than first principles reasons.

I work at smaller scale c++ than google and I found most of their proposals reasonable but undoable for practical reasons rather than first principles reasons. For instance compiler vendors who have a veto power over language changes strongly prefer not breaking ABI. ABI changes are fine if you build the world at every commit, but also if you don't have legacy. C++ users 200 years from now would most likely benefit from the things Google wishes it could do in the language but can't

kllrnohj 4y ago
> ABI changes are fine if you build the world at every commit, but also if you don't have legacy. That's really not true and we can look at other languages to see the various amounts of un-true it is. If ABI constantly changes then what you said is possibly true, but nobody is actually proposing that. The idea instead would be breakage along a std version. Like C++23 would be an ABI break. In the same way Java has had various ABI breaks over the years. You'd be blocked on taking the new ABI until all your dependencies have released updates, sure, but this isn't unheard of or unsolvable. It's also pretty much what you expect from any semvar library, too. API/ABI breaks are quite common outside of monorepos, after all. As long as it's appropriately documented (such as with a major version bump) and there's appropriate dependency tracking, the world can handle it fine. The C++ committee seems to be extremely shy from going this route, though. Even though C++11 triggered some ABI breaks ( https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... ) and everyone seems to have gotten along with that just fine.
- pjmlp 4y ago
  They haven't gotten along with that just fine, that GCC case is exactly what gets brought up when discussing ABI breaks, because it caused a Python 2/3 like experience around the GCC and GNU/Linux communities.
  - kllrnohj 4y ago
    And yet everyone is successfully on C++11 & newer, and that transition still happened in a fraction of the time of the Python 2/3 transition. Nobody even mentions that when discussing modern C++, it's that much of an "everyone got over it" thing.
    - pjmlp 4y ago
      Apparently you aren't much into the C++ world, I advise hearing the C++ podcasts at very least. Plenty of people discuss the matter.
reindeerer 4y ago
ABI with a clear major version number would solve this. It's what C++11 should have done with CoW strings. You just ship 2 version compiled targets of std libs

kllrnohj 4y ago

> ABI changes are fine if you build the world at every commit, but also if you don't have legacy. That's really not true and we can look at other languages to see the various amounts of un-true it is. If ABI constantly changes then what you said is possibly true, but nobody is actually proposing that. The idea instead would be breakage along a std version. Like C++23 would be an ABI break. In the same way Java has had various ABI breaks over the years. You'd be blocked on taking the new ABI until all your dependencies have released updates, sure, but this isn't unheard of or unsolvable. It's also pretty much what you expect from any semvar library, too. API/ABI breaks are quite common outside of monorepos, after all. As long as it's appropriately documented (such as with a major version bump) and there's appropriate dependency tracking, the world can handle it fine. The C++ committee seems to be extremely shy from going this route, though. Even though C++11 triggered some ABI breaks ( https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... ) and everyone seems to have gotten along with that just fine.

pjmlp 4y ago
They haven't gotten along with that just fine, that GCC case is exactly what gets brought up when discussing ABI breaks, because it caused a Python 2/3 like experience around the GCC and GNU/Linux communities.
- kllrnohj 4y ago
  And yet everyone is successfully on C++11 & newer, and that transition still happened in a fraction of the time of the Python 2/3 transition. Nobody even mentions that when discussing modern C++, it's that much of an "everyone got over it" thing.
  - pjmlp 4y ago
    Apparently you aren't much into the C++ world, I advise hearing the C++ podcasts at very least. Plenty of people discuss the matter.

reindeerer 4y ago

ABI with a clear major version number would solve this. It's what C++11 should have done with CoW strings. You just ship 2 version compiled targets of std libs