3 ms·

This is interesting but seems very basic. It looks like it is just lowering types that were previously too complex into C ABI. Notably it doesn't solve anythin

This is interesting but seems very basic. It looks like it is just lowering types that were previously too complex into C ABI. Notably it doesn't solve anything about versioning. I honestly quite like the Swift approach. It isn't zero overhead but it defaults to really good comparability. Basically it adds a vtable for everything including member offsets and object sizes. But the really nice thing is that you can tell the compiler when you don't need compatibility (code and types in the same library, or a library that you statically link) and the overhead just disappears. Of course you lose a few language features (you can't know the size of a type) but then they have tags that you can apply to trade compatibility/flexibility to get those features back.

the_mitsuhiko 4y ago
> Notably it doesn't solve anything about versioning. It does promise backwards compatibility. How is that not sufficient?
- kevincox 4y ago
  That just pushes the problem onto the user. There is lots of well-documented problems with C versioning. Just saying "don't change the size, order, alignment or layout of anything ever" isn't a great option, it can be done (Microsoft has done a pretty good job) but it requires infinite foresight and is very expensive. Swift allows libraries to naturally evolve while maintaining comparability. Most things that you would expect to work (add a new field) just work. Good luck adding a new field to `jmp_buf`. It's effectively impossible to do in an ABI compatible way. The fact that C's ABI is stable/backwards compatible doesn't help. Basically a backwards compatible ABI is the absolute minimum requirement for making backwards compatible libraries. Having more options removes heaps of complexity for library authors.
  - the_mitsuhiko 4y ago
    That’s a fair ask but I’m quite okay with that not being solved. Once the building blocks are stable you can build on top of that.

the_mitsuhiko 4y ago

> Notably it doesn't solve anything about versioning. It does promise backwards compatibility. How is that not sufficient?

kevincox 4y ago
That just pushes the problem onto the user. There is lots of well-documented problems with C versioning. Just saying "don't change the size, order, alignment or layout of anything ever" isn't a great option, it can be done (Microsoft has done a pretty good job) but it requires infinite foresight and is very expensive. Swift allows libraries to naturally evolve while maintaining comparability. Most things that you would expect to work (add a new field) just work. Good luck adding a new field to `jmp_buf`. It's effectively impossible to do in an ABI compatible way. The fact that C's ABI is stable/backwards compatible doesn't help. Basically a backwards compatible ABI is the absolute minimum requirement for making backwards compatible libraries. Having more options removes heaps of complexity for library authors.
- the_mitsuhiko 4y ago
  That’s a fair ask but I’m quite okay with that not being solved. Once the building blocks are stable you can build on top of that.