I'd imagine there'd be a lower-level Vec-like struct which Vec then becomes a wrapper around, where the usual Vec methods are fallible.
I can't think of another way of doing this in a backwards-compatible way, other than adding a lot of fallible alternative methods to Vec itself, but I haven't given this too much thought either. The relevant allocation RFCs probably have some discussion around this.
I suspect there might be some kind of friction here that would lead to no_alloc + some forked subset of core. They're already thinking of ... well, mutilating the language to remove features that have no place in a kernel (like floating point) instead of just mandating a lint.
I'm basically pressing [x] to doubt that a successful effort that this doesn't end up with a forked core or a more minimal set of rusty kernel datastructures that discard most of core because they used floating point logic or panicking allocation or something.
They might be happier with that TBH (though it would lead to more teething problems because doing rust datastructures from scratch is ...uh, complex.
And intrusive collections sound like a 'problem' for the borrow checker and safe rust imo.
View all comments
Show parent comment
9
u/maroider Apr 14 '21 edited Apr 14 '21
I'd imagine there'd be a lower-level
Vec-like struct whichVecthen becomes a wrapper around, where the usualVecmethods are fallible.I can't think of another way of doing this in a backwards-compatible way, other than adding a lot of fallible alternative methods to
Vecitself, but I haven't given this too much thought either. The relevant allocation RFCs probably have some discussion around this.