2 ms·

>First of all this is not embedded in the object file but rather in the header, Rust doesn't need that. Granted, pointed about the header, I was talking more a

by zid 9y ago

>First of all this is not embedded in the object file but rather in the header, Rust doesn't need that. Granted, pointed about the header, I was talking more about the 'int' part but failed to describe myself well at all. I mean more that you can map it onto the ABI properly and easily. Try shuffling internal Rustisms over the usual SysV ABI. What Rust means by anything is still entirely up in the air, and last I checked their bug tracker, the issue had been open for years and was basically commented as "probably won't ever resolve due to rust changing too often". >Furthermore even with the header available a lot of the time C prototypes are not sufficient to know how to use a method. A keyword could be added for that, you wouldn't be able to enforce it on the ABI level but you could make the compiler check the same as Rust. I'm not here to argue about which is better though, I think I accidentally led you up this path though. >Are you talking about name mangling? Rust does that too but that's not really the same issue I need to know how to generate those 'flat names', is the point, I can't call it if I can't name it, and it all plays in from the same systemic issue in that Rust has no idea what it is doing from week to week. EDIT: I'll use this space to re-iterate, if you get rid of all the Rustisms and shuffle everything over the existing SysV ABI, you're left with C. Keeping the Rustisms will need megs of data sending over the ABI somehow to allow Rust to elide bounds checks, etc that Rust is useful for to begin with.

kibwen 9y ago
> What Rust means by anything is still entirely up in the air, and last I checked their bug tracker, the issue had been open for years and was basically commented as "probably won't ever resolve due to rust changing too often". Do you have a link? There's a good chance that issue was opened and that comment made before 1.0, when things really were changing too often. Change is less common these days, though I'm sure the compiler developers do still enjoy not being restrained by the need to maintain ABI backwards-compatibility (which isn't to say they couldn't be convinced, only that it would take cajoling). > it all plays in from the same systemic issue in that Rust has no idea what it is doing from week to week. What do you mean by this? > Keeping the Rustisms will need megs of data sending over the ABI somehow to allow Rust to elide bounds checks, etc that Rust is useful for to begin with. I'm confused here. I don't see how the ABI has anything at all to do with bounds checking; bounds checking, where it exists, is all done at runtime by regular code in the standard library. And by "etc" I presume you're referring to type inference (which you mentioned in an earlier comment), but Rust doesn't do inter-procedural type inference; it's not like Haskell or ML. There's simply nothing to infer, and no need that I can see for an ABI to care about that. Can you be more concrete?
- steveklabnik 9y ago
  They're probably referring to https://github.com/rust-lang/rfcs/issues/600 https://github.com/rust-lang/rfcs/issues/600 It's absolutely true that we have no plans for ABI stability in the near term.

by zid 9y ago

kibwen 9y ago

> What Rust means by anything is still entirely up in the air, and last I checked their bug tracker, the issue had been open for years and was basically commented as "probably won't ever resolve due to rust changing too often". Do you have a link? There's a good chance that issue was opened and that comment made before 1.0, when things really were changing too often. Change is less common these days, though I'm sure the compiler developers do still enjoy not being restrained by the need to maintain ABI backwards-compatibility (which isn't to say they couldn't be convinced, only that it would take cajoling). > it all plays in from the same systemic issue in that Rust has no idea what it is doing from week to week. What do you mean by this? > Keeping the Rustisms will need megs of data sending over the ABI somehow to allow Rust to elide bounds checks, etc that Rust is useful for to begin with. I'm confused here. I don't see how the ABI has anything at all to do with bounds checking; bounds checking, where it exists, is all done at runtime by regular code in the standard library. And by "etc" I presume you're referring to type inference (which you mentioned in an earlier comment), but Rust doesn't do inter-procedural type inference; it's not like Haskell or ML. There's simply nothing to infer, and no need that I can see for an ABI to care about that. Can you be more concrete?

steveklabnik 9y ago
They're probably referring to https://github.com/rust-lang/rfcs/issues/600 https://github.com/rust-lang/rfcs/issues/600 It's absolutely true that we have no plans for ABI stability in the near term.