ABI stability funding [LWN.net]

ABI stability funding

Posted Dec 1, 2025 23:12 UTC (Mon) by NYKevin (subscriber, #129325)
In reply to: ABI stability funding by khim
Parent article: APT Rust requirement raises questions

> The same way Swift did: by permitting !Sized types on stack and so on. Large work, sure, but nothing impossible.

I refer the honorable gentleperson to the answer I gave some moments ago:

> Similar to the previous bullet, this fixes the self receiver and does not help with [associated types, associated functions, and various other dyn-incompatible things besides the self receiver].

to post comments

ABI stability funding

Posted Dec 1, 2025 23:14 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (4 responses)

(And yes, I can see that you wrote a bunch of stuff that boils down to "let's make method dispatch fallible." But that is so obviously absurd that it is undeserving of a serious response.)

ABI stability funding

Posted Dec 1, 2025 23:41 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

One may face random compilation error today with impl even if all formal trait-level checks succeed. Naturally if we want parity between impl and dyn we couldn't skip that quirk, too. And because with dyn they couldn't be done at compile time they have to be done at runtime.

As I have said: that's not a big deal, in practice, the majority of existing software is written in languages that have that “defect” and it's rarely a problem, in practice. Whether Rust team wants to deliver something usable in realistic timeframe or would prefer to punish users with what they have now is up to them, ultimately: using extern "C" doesn't solve that problem, in fact it makes it worse.

ABI stability funding

Posted Dec 2, 2025 8:44 UTC (Tue) by taladar (subscriber, #68407) [Link] (2 responses)

As a Rust user anything that causes more failures at runtime that could instead be compile time failures would be something I would definitely strongly oppose.

ABI stability funding

Posted Dec 2, 2025 10:21 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

We are talking about Rust, not Haskell, here. Uses of extern "C" definitely generates more problems at runtime that higher-level interface ever could — only they generate random crashes, not predictable panics.

In the past for things like integer overflow or array access Rust usually picked up panics in place of UB, but with stable ABI approach is the opposite.

That looks a bit illogical to me, but then, people are not always rational.

ABI stability funding

Posted Dec 9, 2025 0:37 UTC (Tue) by gmatht (subscriber, #58961) [Link]

The current convention for static linking avoids this. If dynamic linking became more common in Rust, making a missing library a compile time error may not be possible, but it would be nice to at least be a link time error.