Is there a reason that `Fallback` is a trait at all?

[TJYSunset]

The current Fallback trait is really awkward to use - it returns &'static strs presumably to avoid allocations or lifetime hell, which means that I must Box::leak() strings if I don't want to hardcode fallbacks. Which leads to the question: why it's a trait in the first place, and not a struct of Vec<String>s (or Vec<Enum> where enum Enum { Static(&'static str), Owned(String) } to avoid allocations)?

I have never heard of a use for font fallbacks that change over time, and even if that's the case, the user could just edit the struct of Vecs if it's allowed mutable access, while results of the Fallback trait are cached into a equally confusing Fallbacks struct that prohibits such behavior. To be honest, the original implementation looks like Java code ported to Rust, where everything must have a interface whether it's needed or not.

I know it's implemented in #369 and could've discussed there instead, but I figure creating a new issue can help users actually benefiting from having such a trait share their thoughts on this. If a trait is unnecessary, I'll be happy to make a PR that converts the trait to a struct of Vecs.

[jackpot51]

I'm open to making changes to it, so long as they only improve flexibility and performance