It came up at the gamedev-wg meeting that the alloc-wg seems (to an outside observer) to be reaching the point where you just have to have a lot of people actually try it out to get a wide range of feedback for much more progress to be made.
However, we're also aware that simply putting the draft version into
alloc can't be done because that would affect Stable users too, which we don't want. At the same time, having the test version not be built into the compiler distribution means there's some parts it can't actually do on its own as an outside crate.
The idea that we had was maybe the whole thing could be put into a nightly-only
alloc_nightly crate? Like as a 100% distinct crate that's just behind a feature flag and distributed in the Nightly distribution. That way the
alloc_nightly can use the "standard library only" things.
alloc_nightly version of the types wouldn't interact at all with the normal
alloc crate's version of the types, so a lot of the ecosystem wouldn't interact well with this, but the kind of people this API needs to serve tend to be the sort who are willing to "build it from scratch" and experiment a bit, so that shouldn't be a big problem for the experimentation phase.
If it’s an entirely separate crate that needs to be opted into, what’s wrong with having it on crates.io?
“Standard library only things” are unstable through the same
#![feature(…)] mechanism as feature destined to be stabilized eventually
What would be the difference between
If the whole point is just to try this out, a crate in crates.io seems like the right place.
This means that if you try to pass an
alloc_wg::Vec to an API expecting
alloc::Vec your code will fail to compile
alloc_wg could add some interfacing
From impls, that allow converting between these types when possible ?
Its still going to have some friction.
I was told that there are some compiler features to try out that are restricted to only use within the standard library. If this is not the case then crates.io would be totally fine as a distribution method.
#![feature(…)] is how those restrictions are implemented
I know about lang features. However, in another project when I tried to use the
since attribute it errored on being standard library only and with no possible lang feature for using it outside of the standard library. It's just impossible. So such things so exist.
In this particular case, I have not been using alloc-wg myself, most of the testing was by another user in the gamedev-wg. Unfortunately this means that I don't know every detail. I was just the person who had the most time to communicate the message and follow up :P
So, if the initial assessment was wrong and the crates.io version of the crate really has all possible abilities then that's fine, no need for any changes.
when I tried to use the
sinceattribute it errored on being standard library only
alloc_wgcould add some interfacing
Fromimpls, that allow converting between these types when possible ?
Feel free to make a Pull Request! :)
I'm not sure is worth it, e.g., if you want to experiment with
alloc_wg, then you are going to need nightly anyways, and you can work around certain things already.
If there are particular examples causing friction, that's one of the things that we could do
(e.g. for going from
Vec::from_raw_parts ought to work, but I can see how that's tiresome)
A dedicated conversion API could ensure the allocators match
from_raw_parts with a pointer from a different allocator is not good
Sure, but users can write traits for those conversions themselves, and if they happen often, we could move them into