On Sat, Jul 11, 2015 at 9:36 PM, David Jeske <dav...@gmail.com> wrote: > In the realm of non-gc (non world stop) languages, swift, compared to c++, > offers superior separate compilation binary compatibility. In fact, I argue > c++ is basically a whole program compiler. > > In c++, neither parametrics, nor subclassing are binary upgradable across > separate compilation units. Swift can upgrade both across compilation > units.. > > There are few non-gc non-vm object systems which support binary upgradable > separate compilation. They include obj-c, swift, and com.
I have a hard time imagining that the ability to calculate sizes and offsets of fields should be the responsibility of anything but either the known or unknown status of the value of a type variable, or any excuses that can convince me that its worthwhile to implement partially defined types absent type variables which would force you to implement relocation for accessing fields within a type... even if it means type variables which exist across multiple phases of compilation. The position independent ABI's must still match is the checking of such not best viewed as a part of the compilation process? if they do not match hopefully the errors occur sooner rather than later, either via the linker or dynamic linker, opposed to a runtime error, I suppose that doesn't affect the views on separate compilation... anyhow I still think the best way to avoid the fragile base class problem is to avoid base classes entirely...instead moving to a system-fω where inheritance is pushed to type variables in the previous phase of compilation, this keeps the known/unknown shape/offset dichotomy intact, and separate compilation should be possible as long as binaries contain only known types... _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
