`tuple_array_conversions` lint makes code less readable when slice is involved

[Aaron1011]

Summary

I tried this code:

fn main() {
    let (a, b) = (1.0f64, 2.0f64);
    let _foo: &[f64] = &[a, b];
}

However, using .into() in this situation doesn't work, as the compiler infers the unsized type [f64]:

fn main() {
    let tuple = (1.0f64, 2.0f64);
    let _foo: &[f64] = &tuple.into();
}

produces:

error[[E0277]](https://doc.rust-lang.org/nightly/error_codes/E0277.html): the trait bound `[f64]: From<(f64, f64)>` is not satisfied
 --> src/main.rs:3:31
  |
3 |     let _foo: &[f64] = &tuple.into();
  |                               ^^^^ the trait `From<(f64, f64)>` is not implemented for `[f64]`
  |

Using <[T; N]>::from works - however, IMO this code is significantly less readable:

fn main() {
    let tuple = (1.0f64, 2.0f64);
    let _foo: &[f64] = &<[f64; 2]>::from(tuple);
}

I would argue that the original code is the most readable in this situation (constructing a slice from a tuple), and this lint should not fire when a slice is involved.

Lint Name

tuple_array_conversions

Reproducer

I tried this code:

fn main() {
    let (a, b) = (1.0f64, 2.0f64);
    let _foo: &[f64] = &[a, b];
}

However, using .into() in this situation doesn't work, as the compiler infers the unsized type [f64]:

fn main() {
    let tuple = (1.0f64, 2.0f64);
    let _foo: &[f64] = &tuple.into();
}

produces:

error[[E0277]](https://doc.rust-lang.org/nightly/error_codes/E0277.html): the trait bound `[f64]: From<(f64, f64)>` is not satisfied
 --> src/main.rs:3:31
  |
3 |     let _foo: &[f64] = &tuple.into();
  |                               ^^^^ the trait `From<(f64, f64)>` is not implemented for `[f64]`
  |

Version

rustc 1.72.0-nightly (839e9a6e1 2023-07-02)
binary: rustc
commit-hash: 839e9a6e1210934fd24b15548b811a97c77138fc
commit-date: 2023-07-02
host: x86_64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

Additional Labels

No response

[Centri3]

I think it should still lint, it prevents you from updating (a, b) to (a, b, c) and forgetting to update _foo at the same time. It's not just readability (though imo, I prefer the explicitness of &<[f64; 2]>::from(...))