Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> If it is in fact an ABI break, how much of an obstacle would that be to getting this through the committee?

In my understanding:

Historically, the committee basically said "if your paper breaks the ABI, it won't be considered, don't bother." In Prague last month, the committee voted that C++23 would not break ABI, though that decision is not final. However, they did say that authors should bring papers that would break the ABI, and they will be considered in a general sense.

So, it is now possible, at least.



That's fair. I suppose the next question would be what it would take to get the committee to stop kicking the can down the road and actually vote to break ABI, since "considered" is a fairly weak promise. Perhaps they're waiting to see what people come up with?


I was not in attendance, but from what I read on /r/cpp, at least some people thought that the discussion was brought up in sort of a suboptimal way, and that there was actually a lot of support in the room for breaking the ABI. Regardless, I think that what was decided is clearly in this direction.


I'm curious to see where C++ will go from here on out then. If only they were open to breaking API too to fix things like unordered_map...

By the way, I know Rust doesn't guarantee a stable ABI, but has Rust gotten significant improvements out of not making that guarantee?


The main improvement is not spending time and energy to define such a thing and maintain it.

We have done some breaking stuff too, and that has been useful, but in my mind, that’s less important.


That's fair. Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: