Update arrayvec

[c410-f3r]

Glad to wait until you feel comfortable with the new minimum Rustc version.

[paupino]

Thank you for updating this! For (my) reference, this requires a minimum Rust version of 1.51.

[paupino]

Sorry - I realize the latest changes in master will break this build (again). The fix is to bump the minimum version specified in the github workflow file. I just wanted to make sure the minimum version was explicit going forward.

[c410-f3r]

Sup @paupino. Don't worry!

[paupino]

I've been thinking how we can keep this up to date as much as possible while still maintaining minimal compiler support.

One way, which avoids bumping the minimum version, is to move arrayvec usage into a feature - perhaps as a default feature. It'd mean that the non-arrayvec feature would need to be reimplemented (using String etc). I played around with this a little bit and got it working but it is quite a bit slower (over 4x-5x). Perhaps that's acceptable if arrayvec is enabled by default?

On the other hand: it would be nice to start thinking about how to leverage some new compiler features within the library itself. I guess the other alternative is to create an LTS branch which would commit to minor big fixes, whilst still allowing the main branch to continue moving forward.

I'm perhaps leaning towards an LTS since it'd be nice to expand support within the library, particularly with the new edition around the corner.

Thoughts?

[schungx]

I am mostly keeping bug fixes on the main line, and a vnext or dev branch for new developments. However, I find that, in practice, this may not be optimal. The main problem is with keep the dev branch updated with bug fixes.

What you suggest, i.e. to keep a bug-fixes branch and develop on the main line might actually be better. I'm going to migrate one of my projects to this style and try it out.

[c410-f3r]

My initial thoughts:

Optional features

arrayvec_0_6 = { optional = true, package = "arrayvec", version = "0.6" }
arrayvec_0_7 = { optional = true, package = "arrayvec", version = "0.7" }

Does not work because:

1. Introduces a cumbersome breaking change forcing everybody to explicitly set the desired arrayvec dependency version.
2. Cargo features are additives so a default = [arrayvec_0_6] won't go away when setting --feature arrayvec_0_7
3. build.rs does not set cargo features, only rust flags.

LTS

Rust does not support LTS compilers and simply ask ppl to update their toolchains when a security issue is discovered and fixed on the standard library or in the language itself. But hey, it doesn't work because a lot of ppl are relying and deploying software based on a fixed version.

Conclusion

With all that said, I really don't know the best solution for this scenario

[schungx]

IMHO, just wait a bit until compiler installations catch up. I can't see users of Rust are very reluctant to upgrade versions... maybe not immediately, but definitely once in a while to catch up.

That's like Chrome and others where you basically just update without second thoughts, even in many corporate environments.

[c410-f3r]

Hum... Per the recent Minimum Rust Compiler Version comment, it seems that the ArrayVec update is now possible.

Is that right, @paupino? If so, it would be awesome because my heart cries every time I type cargo tree -d.

[c410-f3r]

Ah, NVM. Such feature will only the possible on 2022/03/25.

[paupino]

I wonder if support n - 5 versions is better than the 1 year constraint? This equates to approximately half a year. Of course, it would be only on an "as needed" basis - so the minimum would be bumped to 1.50.

I'd also love to get this wrapped up and start playing with const generics! :)

[c410-f3r]

Re-based in case the constraint is relaxed. IMHO, constant generics is a huge milestone that is worth supporting.

[c410-f3r]

Thanks @paupino 🙃