-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Disallow coercions from [T, ..n] to &[T] #18645
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
Part of #18469 |
@@ -576,11 +576,11 @@ pub trait MutableSliceAllocating<T> for Sized? { | |||
/// ```rust | |||
/// let mut v = [5i, 4, 1, 3, 2]; | |||
/// v.sort_by(|a, b| a.cmp(b)); | |||
/// assert!(v == [1, 2, 3, 4, 5]); | |||
/// assert!(v == &[1, 2, 3, 4, 5]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm under the impression that this change won't be necessary once #18486 lands. Since [T, ..N] == [T, ..N]
works up to N = 32
. cc @nikomatsakis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems correct
r=me, thanks @nick29581! |
The forwards compatible parts of #18645, rebased. Converts implicit coercions from `[T, ..n]` to `&[T]` into explicit references.
[breaking-change] Insert an `&` to fix
r? (I realise this needs a rebase, but I will probably have to chop it up in order to land and I'd like to get r+ first so I can do that quicker)
fix: Non-exhaustive structs may be empty
r?
(I realise this needs a rebase, but I will probably have to chop it up in order to land and I'd like to get r+ first so I can do that quicker)