If the order is specified explicitly, with each method's index in the vtable declared in an attribute, would that allow adding methods to be backwards-compatible?
1 Like
Yeah, so long as new items in a vtable are appended after existing items, &Vtable_1_1_0 can transparently be used as &Vtable_1_0_0... with the caveat that this only works if vtables are only provided within the same static unit as defines it, because going the other direction won't work. (Including the vtable version in the header allows detecting this error condition, but it's still a fatal error.)
Thankfully, you don't need to uniquely number every single item; you just need to specify what version they were added in, and the compiler can sort within the set stabilized in a given update.
I suspect that if vtable stability happens, it'll probably look like #[stable(since = "1.0.0")] stability annotations. #[unstable] functions can even still be included in the vtable after all stable items, but only usable by statically linked code.
Essentially, you're still defining a new subtrait Vtable_1_1_0: Vtable_1_0_0, where an upcast is a noöp since the supervtable is a prefix of the subvtable. There just needs to be some mechanism to make sure you don't try to downcast a vtable if you can't prove all implementations are actually for the subtrait.
(Caveat: provenance and subobject slicing... “just” don't do that for vtables you want to downcast okay?)
What you're actually concerned with here is not just backwards compatibility, but also (a subset of) forwards compatibility. You can make any A{BP}I backwards compatible by just not changing anything; the interesting part is what changes your consumers are forwards compatible with.
2 Likes
I've updated the first post with a summary of discussions so far. Please let me know if you think I've missed something that should be put in the summary.
1 Like
I also want to voice my opinion that Rust's stable ABI should closely match (or match exactly) the Canonical WebAssembly Component Model ABI.
OK, I've seen enough traffic on here and on the Zulip channel to know that there is interest in this. What are the next steps? Set up a Github project, do something formal with the Rust team, what? I can act as a sort-of manager, pushing the team along, but I'm by no means an expert in this area and can only really act as a cheerleader and driving force, and maybe a maintainer/editor of documentation. Moreover, I can't do this on my own; it really needs to be a Rust initiative to ensure that there is enough clout and momentum behind it that it gets accepted.
So, where do we go from here?
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.