Polymorphic array and byte string literls [T; N]/[T]

Array literals ([1, 2, 3]) and byte string literals (b"abcd") have their length as a part of their type, because sometimes it's crucial to know the length at compile time.
This approach have a couple of downsides:

• First, every time these literals interact with generics it is an invitation to code bloat, because literals with different lengths generate different instantiations of generics. (On the other hand, this code bloat has a chance to be counterbalanced by better const propagation in specialized code and further optimizations.)
• Second, it leads to inconveniences like https://github.com/rust-lang/rust/issues/21725, i.e. some extra traits have to be implemented for fixed arrays of different sizes in order for array literals to be usable in some contexts.

In practice, most of the time the length is needed only at runtime and can be erased from the type of an array or byte string literal.
So, my suggestion is to make array and byte string literals polymorphic, similarly to integer literals. They will have dynamically sized type by default and statically sized type when necessary (this part requires better specification and implementation experience).
(String literals could be made polymorphic too, when something like FixedString<N> is implementable.)

Currently array and byte string patterns behave somewhat similarly - they adapt to the type of the match discriminant and denote either sized or unsized arrays.

Start by reading the proposal and the linked issue #21725, then investigate how array and byte string literals currently interact with generic types and patterns. The issue says the required specification and implementation experience are still missing; done would require an agreed design and an implementation plan for polymorphic literal types.