implement Default for all arrays

[lcnr]

Using feature(marker_trait_attr) and a new lang item array_default_hack, we're able to implement Default for generic arrays without relying on any too unstable features.

cc https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/array.20default.20impls

r? @nikomatsakis 💖

[lcnr]

ok, we definitely need to use marker_trait_attr.

We only consider the auto trait impl if the manual impl does not shallowly match. So if our manual impl has a ty param as the self type, we never actually use the auto trait one.

If we manually impl the 0 case it influences type inference which is also bad.

[clarfonthey]

Is there a reason why this has to add extra lang items? Why not just use MaybeUninit::uninit_array and set Default::default() to each item?

I'm a bit confused why the N = 0 case is a problem,

[lcnr]

I'm a bit confused why the N = 0 case is a problem,

Default is implemented for [T; 0] even if T does not implement default. We can't use <T as Default>::default() in the implementation directly because T might not implement it.

[jhpratt]

Worth noting that with min_specialization the lang item wouldn't be necessary as you could impl<T: Default, const N: usize> Default for [T; N] and impl<T> Default for [T; 0] at the same time. As such, this lang item should be temporary in the long-term.

[coolreader18]

you could impl<T: Default, const N: usize> Default for [T; N] and impl<T> Default for [T; 0]

Could you? I was under the impression specialization on const generics was more complicated/unimplemented/at least requires const_evaluatable_unchecked

[jhpratt]

Yeah, looks like currently on nightly this doesn't work. I would think that this could be done in the future, though. My point of it being temporary in the long-term is still relevant.

error[E0275]: overflow evaluating the requirement `[_; 0]: Default`
  |
  = help: consider adding a `#![recursion_limit="256"]` attribute to your crate (`default-demo`)
  = note: required because of the requirements on the impl of `Default` for `[_; 0]`
  = note: 127 redundant requirements hidden
  = note: required because of the requirements on the impl of `Default` for `[_; 0]`

[nikomatsakis]

We discussed this in the const generics meeting this morning. This intersects and somewhat constraints specialization in that it uses a lang-item to effectively simulate a pair of impls:

• one for [T; 0]
• and one for [T; N] where T: Default

This cannot be covered by the specialization plans as they stand today. It is conceivable, though, to imagine accepting it in the future. The key would be that we don't need to know whether T: Default in order to know if the second impl applies, we only hav to know if N == 0 or not (and the type checker will have guaranteed T: Default). So we don't need all the "always applicable" machinery. I'm not sure how to express this idea logically yet, haven't tried.

There would be a problem if you have a further impl like [T; N] where T: Default + Debug, but that's a separate issue.

[nikomatsakis]

I'm going to nominate for @rust-lang/lang discussion on the previous comment.

[bors]

☔ The latest upstream changes (presumably #84730) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting, and we're in favor of having this Default impl, as long as @rust-lang/lang is comfortable with the hack(s) necessary to make it possible.

[m-ou-se]

From a library implementation perspective: The code that this PR adds in library/core/src/array/mod.rs does not look like something we can maintain. If a PR comes in that changes that code, I do not think we have the right reviewers to be able to judge not only correctness, but also what such a change means for our stability guarantees. I'd like to avoid having blobs of 'don't touch this'-code in the library.

[nikomatsakis]

So in our @rust-lang/lang meeting on 2021-06-29, we discussed this proposal again, and in particular we discussed @m-ou-se's implementation concerns. Our sense is that we feel comfortable with the idea of [T; N] implementing Default when either T: Default or N = 0, but if this particular route of achieving that goal feels like an overly hacky or risky maintenance burden, we don't want to pursue it. We'd prefer to add a cleaner language feature to that end. Therefore, I'm going to close this PR. Thanks @lcnr for the clever idea. 💜