Stream: t-libs/wg-allocators

Topic: When can an experimental version get into Nightly?


Lokathor (Jan 08 2020 at 21:40, on Zulip):

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.

Obviously the 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.

Thoughts?

Simon Sapin (Jan 08 2020 at 23:42, on Zulip):

If it’s an entirely separate crate that needs to be opted into, what’s wrong with having it on crates.io?

Simon Sapin (Jan 08 2020 at 23:43, on Zulip):

“Standard library only things” are unstable through the same #![feature(…)] mechanism as feature destined to be stabilized eventually

Tim Diekmann (Jan 09 2020 at 12:12, on Zulip):

What would be the difference between alloc-nightly and alloc-wg?

gnzlbg (Jan 09 2020 at 17:35, on Zulip):

If the whole point is just to try this out, a crate in crates.io seems like the right place.

gnzlbg (Jan 09 2020 at 17:36, on Zulip):

This means that if you try to pass an alloc_wg::Vec to an API expecting alloc::Vec your code will fail to compile

gnzlbg (Jan 09 2020 at 17:37, on Zulip):

Maybe alloc_wg could add some interfacing From impls, that allow converting between these types when possible ?

gnzlbg (Jan 09 2020 at 17:37, on Zulip):

Its still going to have some friction.

Lokathor (Jan 09 2020 at 17:58, on Zulip):

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.

Simon Sapin (Jan 09 2020 at 18:06, on Zulip):

#![feature(…)] is how those restrictions are implemented

Lokathor (Jan 09 2020 at 18:29, on Zulip):

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.

Simon Sapin (Jan 09 2020 at 18:32, on Zulip):

when I tried to use the since attribute it errored on being standard library only

That’s likely #[feature(staged_api)]

Tim Diekmann (Jan 10 2020 at 11:16, on Zulip):

Maybe alloc_wg could add some interfacing From impls, that allow converting between these types when possible ?

Feel free to make a Pull Request! :)

gnzlbg (Jan 10 2020 at 15:17, on Zulip):

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.

gnzlbg (Jan 10 2020 at 15:18, on Zulip):

If there are particular examples causing friction, that's one of the things that we could do

gnzlbg (Jan 10 2020 at 15:21, on Zulip):

(e.g. for going from alloc_wg::Vec to std::Vec an .into_raw_parts() + Vec::from_raw_parts ought to work, but I can see how that's tiresome)

Simon Sapin (Jan 10 2020 at 19:51, on Zulip):

A dedicated conversion API could ensure the allocators match

Simon Sapin (Jan 10 2020 at 19:52, on Zulip):

from_raw_parts with a pointer from a different allocator is not good

gnzlbg (Jan 11 2020 at 13:58, on Zulip):

Sure, but users can write traits for those conversions themselves, and if they happen often, we could move them into wg_alloc

Last update: Jan 28 2020 at 00:40UTC