feat+refactor: Bump MSRV to 1.83.0 and maximize const

[Daniel-Aaron-Bloom]

Find every fn which can be const (as of 1.83.0) and make it so. This involved moving all the implementations out of the ArrayVecImpl trait, which eventually left it unused, so I removed it.

You could probably also remove MakeMaybeUninit and just have new_const call new if you wanted to.

[tbu-]

What's your motivation for this pull request? This currently raises the MSRV quite substantially, so it should have a good motivation, at the very least.

[Daniel-Aaron-Bloom]

I made this crate, and doing that was my motivation.

The summary is: now that &mut is const-compatible, you can make almost everything in ArrayVec into a const fn. Having a mut ArrayVec at compile-time is extremely powerful.

For now I've just forked this crate as arrayvec-const, but that's basically just a hack.

[Daniel-Aaron-Bloom]

Do you think this would be better served via a feature-flag?

[cmrschwarz]

I would love if we could have something like this 👍 , honestly sooner rather than later as it blocks downstream libraries.

1.83 marks a huge shift in whats possible in const and anybody trying to currently use arrayvec
in programs that want to take advantage of that is just completely out of luck.

A minimal version of this that would be sufficient for libraries would be a const_as_mut_ptr feature flag that would opt in to 1.83. It would mark the following two functions as const (both of these are one liners so having a cfg'd duplicate should be acceptible):

• as_mut_ptr
• set_len
  This would expose enough of ArrayVecs internals for a downstream library / program willing to use unsafe to do what it needs to in const code.

[Daniel-Aaron-Bloom]

I've created #296 as an alternative to this with the changes under the feature flag const.

Instead of cfg duplicating the code, I just cfg duplicated a macro that basically just adds or removes const based on the flag.

[JSorngard]

Something interesting for this PR might be the crate rustversion which can conditionally mark functions as const if the user is using a modern enough compiler, and leave the function non-const otherwise. Then you might be able to merge this PR without raising the MSRV (though I haven't looked at the code close enough to say this for sure).

It would however add a dependency on a proc-macro crate.

[LinusU]

Just chiming in with my use case for this, would love to see this landed in some form 🤩

I want to create structures at compile time which contains ArrayVec. I then use &'static references to these structures and use them throughout my game. Currently, I've solved this by using a slice instead. But I would have preferred to be able to use ArrayVec as I already have a helper structure for this particular array: Moveset

Huge thanks to op for putting this together 🙌