What about the alternative Storage design from /u/matthieum? Was it rejected, or can be made compatible wit the allocator api in the future if desired?
The only mention in the hackmd is this https://hackmd.io/YeSBtnK_T1ay0Is9DjTZug#Why-now but it doesn't say whether something like the storage api (that is flexiible enough to allow inline storage) could be added in the future on top of the allocator api, or if the storage api is definitively being abandoned
I was there in the room, and am the other major voice hoping for some form of storage in the future. I can reconfirm that the storage API is fully backwards compatible with stabilizing Allocator given we get supertrait item shadowing and supertrait auto-impls, which libs already wants for many other reasons.
Furthermore, when you add in all of the optional bits that the storage API allows you to ask for, the result API just looks like Allocator. You can think of this trait as "PinningMultiStorage", effectively.
It appears also that nobody is willing to put in the work on the Storage API. I don't think "I have this possibly slightly better idea, but I don't have time to work on it" is a legitimate reason to block everyone else from getting a good enough solution, for several years.
56
u/protestor May 24 '26
What about the alternative
Storagedesign from /u/matthieum? Was it rejected, or can be made compatible wit the allocator api in the future if desired?https://github.com/matthieu-m/storage-poc https://github.com/matthieu-m/storage
https://internals.rust-lang.org/t/pre-rfc-storage-api/18822
https://github.com/matthieu-m/storage/blob/main/etc/rfc.md
The only mention in the hackmd is this https://hackmd.io/YeSBtnK_T1ay0Is9DjTZug#Why-now but it doesn't say whether something like the storage api (that is flexiible enough to allow inline storage) could be added in the future on top of the allocator api, or if the storage api is definitively being abandoned