Tracking Towards 2.0

[Lokathor]

In 2.0 we want to use const generics so that ArrayVec is available for far more lengths than just the handful of lengths we declare.

• The main snag is that we need to be able to Default the array. This requires either that Default be implemented for any array length (seems far out, if at all?) or we need to have array_map become stable. If array_map becomes stable you just write [(); N].map(|()| T::default() ) and move on with life.

[paolobarbolini]

It looks like v1 already supports min_const_generics behind a feature flag. Couldn't any future development be done on that instead of splitting the ecosystem in half by releasing a new major version?

[Lokathor]

This crate's (perhaps aggressive) policy is that increasing the required minimum rust version is breaking. This will continue to be the case until cargo's version resolver gets a lot smarter.

However I don't imagine there will be any major ecosystem split because (from what ive seen) most usage of the crate is internal, not in a public api.

[paolobarbolini]

I like the policy of bumping the MSRV in major versions.

I see however that you already went down the route of making it possible to conditionally bump the MSRV, by adding the rustc_1_40 feature flag. I really liked the idea, and I applied it to a crate that I recently published. What if support for const generics were to be done the same way? In a sense it already is, since it has been put behind the nightly_const_generics feature flag, so unless there are breaking changes to be done to the public API, why not continue down the v1 path?

[Lokathor]

We could continue v1 for quite a while like that I suppose. I'm not the most enthusiastic about having both code paths in the crate forever, but it wouldn't kill us.

[saethlin]

rust-lang/rust#87174

[Lokathor]

Looks like the date will be 2021-09-09

[5225225]

Heads up, array map has been stable for a while now, as has const generics.

[Lokathor]

Yeah. I think that the current situation is that things are imperfect, but basically "good enough" so that any further changes would be only small improvements. Small enough that maybe they don't justify a breaking change.

I think that for now I'll actually close this issue entirely. I certainly don't mean that there will never be a 2.0 of this crate, but I don't have any plans to do it myself, and no one has spoken to me about actually doing it. Given that the rustc_1_55 feature is available in the crate then that's probably good enough for the foreseeable future.