Description
I was meandering through the Rust library source code when I stumbled across this glorious gem:
// The Default impls cannot be done with const generics because `[T; 0]` doesn't
// require Default to be implemented, and having different impl blocks for
// different numbers isn't supported yet.
macro_rules! array_impl_default {
{$n:expr, $t:ident $($ts:ident)*} => {
#[stable(since = "1.4.0", feature = "array_default")]
#[rustc_const_unstable(feature = "const_default_impls", issue = "87864")]
impl<T> const Default for [T; $n] where T: ~const Default {
fn default() -> [T; $n] {
[$t::default(), $($ts::default()),*]
}
}
array_impl_default!{($n - 1), $($ts)*}
};
{$n:expr,} => {
#[stable(since = "1.4.0", feature = "array_default")]
#[rustc_const_unstable(feature = "const_default_impls", issue = "87864")]
impl<T> const Default for [T; $n] {
fn default() -> [T; $n] { [] }
}
};
}
array_impl_default! {32, T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T}Can anyone please tell me what is so important about [T; 0]'s Default impl to the point that it warrants code as... well, I hate to say it but, vile and disgusting as this?
I found this diamond in the rough when I noticed that Default was only implemented for [T; N] up to [T; 32]; I instantly assumed code repetition (for which I was sort of right, ugly macro), and swooped in to save the day with const generics... or so I thought??
Is there a reason why core::array::from_fn cannot be simply be used? I personally do not believe that the performance benefit outweighs the flexibility and SEVERE code quality penalty. What are your thoughts, though?
And if whoever happens to be reviewing this issue sides with me on the matter, then can I just go ahead and get rid of this demon?