|
|
|
|
|
by tialaramex
986 days ago
|
|
Actual stdlibs tend to be magic. Take Rust's NonZeroU8. This type is an unsigned byte which isn't zero, but as a result the bit pattern where zero would fit is unoccupied and thus Option<NonZeroU8> is also a single byte. This allows code which has the safety and convenience of modern type safety where we can't screw up and forget that None isn't just zero - yet also the performance of a C-style sentinel trick where you just treat zero as indicating None, maybe using macros. But, you can't make such types in your own Rust. If you wish you had NonSixU8, a type which can't be six, the only way to make it would be to base it on NonZeroU8 and use some sort of XOR scheme. The standard library is blessed with the ability to do this even though it's not available to mortals and that blessing is only open in practice to the actual standard library for the entirely practical reason that only they can co-ordinate with the compiler team to ensure it happens - if the Rust compiler re-defines how niches work the library team have to change NonZeroU8 at the same time. So while the actual stdlibs get to do magic, which makes them stand out from a popular third party library like SDL or zlib, these "alternatives" don't. If they provide all the same stuff as the "real" standard library that makes sense, but when they instead provide different stuff and they can't do magic I don't see any difference from any other library. Is SDL an "alternate stdlib" if we and some friends all use it all the time? |
|
Those are unstable, so you have to use another attribute opt in to using them. But you can absolutely put them on your own type.
There's nearly nothing in the Rust stdlib you can't write yourself. OIf I recall correctly one example is the function Box::new which constructs a heap allocated smart pointer to it's argument. It "magically" skips allocating the argument on the stack of the caller in some situations.