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.