Support arrays

[TonalidadeHidrica]

Sometimes it is useful to use an array (e.g. [i32; 2]) instead of a homogeneous type ((i32; i32)). Can we try to support arrays in input! macro? At least, current syntax [i32; n] collides with the array syntax, so we will have to think of workaround.

[qryxip]

How about [T; const { CONST_EXPR }]?

It seems to be actually valid as a type. (even I was surprised) https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f173ff5d92c0ce9e620896a2b657f067

[TonalidadeHidrica]

That's possible, although I'm not quite in favor of it. Some alternatives:

• Rename current [i32; n] with vec![i32; n] (or vec[i32; n]?), and accept [i32; 2] as an array
• Introduce array![i32; n] as an array, leaving [i32; n] for vectors

[qryxip]

Considering notations like [T; 1 + const { 1 }] are also valid as types, what I said was not good.

Alternatives I can come up with... hmm... perhaps just adding proconio::marker::Array<T, const N: usize> is enough...?

[statiolake]

Sorry for the late reply! Thanks for the new idea. Although I'm still not sure when it would be actually useful to directly read arrays, I think adding a new marker type would be a good idea, as mentioned in @qryxip's last comment.

Considering that a lot of people are using the library now, we should avoid breaking changes as much as possible. I'm afraid renaming [i32; n] to other forms or changing [i32; n] from Vec to array would be too drastic. Also, we have the notation [i32] for reading Vec of dynamic length, which cannot be achieved with arrays.

Introducing array![i32; n] seems a bit counterintuitive, since users would expect variable: Type to be a basic syntax of the macro and array![i32; n] doesn't look like a type (considering that vec![i32; n] is rather a constructor than a type). [T; const { n }] seems also counterintuitive, since [T; N] with const N: i32 = 3; would not be an array.

[TonalidadeHidrica]

Thank you for kindly rigously refuting the other options. I definitely think Array<T, N> marker would be the best. If somebody (maybe me?) is willing to implement, we should go with that syntax for sure!