Replace Vec and String with FixedArray and FixedString for all models

[GnomedDev]

This shrinks type sizes by a lot however makes the user experience slightly different:

• FixedString must be converted to String with .into() or .into_string() before it can be pushed to, but derefs to &str as is.
• FixedArray must be converted to Vec with .into() or .into_vec() before it can be pushed to, but derefs to &[T] as is.

Currently this is a git dependency, but I hope that is fine for next. I want to get some basic testing in serenity before I push to crates.io.

[mkrasnitski]

Without taking a look at the changes, what's the benefit of these types over ArrayVec and ArrayString from the arrayvec crate?

[GnomedDev]

ArrayVec and ArrayString are both inline allocated and have a compile time max capacity
FixedArray and FixedString are both heap allocated, have a max length of u32::MAX, and don't store capacity

[mkrasnitski]

Looking at the lib, it seems like there are no mutable APIs for either of the types? If that's the case, why not then use boxed arrays? At the very least, at a cursory glance I'm not convinced the FixedString API is all that sound - I think it would be best to replace that with Box<str>, which is guaranteed sound.

[GnomedDev]

Can you read the module level documentation of the lib?

These can be thought of as Box<[T]> and Box<str>, except the length is denoted as a [u32].

As for the soundness, there is very little unsafe in the library, and you are free to audit it, but it's pretty simple and I can't see many failure points.

[ultrabear]

theres a bit of UB (that i can see) that is amendable by erroring on platforms where pointer width is not 32 or 64 bit

UB in question

    fn len(&self) -> usize {
        self.small_len() as usize
    }

[GnomedDev]

Can you move that to an issue on the repo, instead of here, although thanks for letting me know, I'll see if I can restriction lint out as entirely.

[mkrasnitski]

Can you read the module level documentation of the lib?

Apologies about that, I wasn't being very careful with my skimming.

With regards to the size of the struct, we're already saving a usize for capacity, which we can assume is 8 bytes. However, an extra 4 bytes of size is not worth the extra maintenance burden IMO, considering this type would be included in basically every model type, and in some cases be user facing. The deref impl definitely helps, but IMO it would still be too exotic.

[GnomedDev]

I know I've floated the idea before, but how about an unstable-optimisations feature flag to swap implementations for this stuff around. It could be Box for most users and FixedString for crazy people.

[mkrasnitski]

I know I've floated the idea before, but how about an unstable-optimisations feature flag to swap implementations for this stuff around. It could be Box for most users and FixedString for crazy people.

This could work and would save you the headache of maintaining a fork. That work could be made in a separate PR, as the sizable savings already incurred from switching to Box are worth merging on their own merit.