Why ops::Index<Idx> allows unsized Idx?

[matklad]

Today I’ve noticed that Index is defined as follows:

pub trait Index<Idx: ?Sized> {
    #[stable(feature = "rust1", since = "1.0.0")]
    type Output: ?Sized;

    #[stable(feature = "rust1", since = "1.0.0")]
    fn index(&self, index: Idx) -> &Self::Output;
}

why do we need Idx: ?Sized if we accept index by value anyway? Shouldn’t https://github.com/rust-lang/rust/pull/23601 removed this anti-bound as well?

[Centril]

One can use unsized_locals for this… Here’s just an example to make it compile:

#![feature(unsized_locals)]

use core::ops::Index;
use core::fmt::Debug;

type A<'a> = &'a dyn Index<dyn Debug, Output = u8>;

fn main() {
    let x: A<'_> = panic!();
    let y: dyn Debug = *(&0 as &dyn Debug);
    x.index(y);
}

If that is useful remains to be seen. However, it is a breaking change to enforce Idx: Sized.

[matklad]

However, it is a breaking change to enforce Idx: Sized .

I wonder if there’s real code that breaks. rust-lang/rust test suite passes if I remove the bound.

EDIT: which probably means that we either need to remove the bound, or to add a test for it.

[Centril]

I wonder if there’s real code that breaks. rust-lang/rust test suite passes if I remove the bound.

Unlikely I think because of the lack of stable unsized_locals. However, I rather leave the un-bound in for future-compat purposes. Is there a specific reason you want to remove ?Sized?

EDIT: which probably means that we either need to remove the bound, or to add a test for it.

I would happily r+ a PR that adds a test! Thank you for discovering the lack thereof.

[matklad]

Is there a specific reason you want to remove ?Sized ?

Consistency: we generally don’t have ?Sized bounds unless there’s a strong reason to have one. For example, Add is defined as trait Add<RHS=Self>.

I definitely think that we should not blindly add a test for this. I guess I’ll send a PR for the libs team to review. It may be the case that we want this to be ?Sized, but than we need to figure out if we can change over operators to follow the suite.

EDIT: PR is up https://github.com/rust-lang/rust/pull/59527

[Centril]

Consistency: we generally don’t have ?Sized bounds unless there’s a strong reason to have one. For example, Add is defined as trait Add<RHS=Self> .

Hmm… I mostly was looking for a use-case. Consistency is valuable, but I wouldn’t want to reduce future potential expressiveness just for that.

I definitely think that we should not blindly add a test for this.

The test can easily be removed whenever, there’s no problem in adding it now.

[matklad]

That’s an extremely personal opinion, but I prefer to reduce expressiveness of things unless there’s a strong reason that expressiveness is required Expressiveness and “easy to understand” tend to oppose each other (https://www.tedinski.com/2018/01/30/the-one-ring-problem-abstraction-and-power.html is a good blog post on this topic).

In this particular cases, I imagine that, with by-value DSTs implemented, someone might accidentally write Index<[usize]> instead of Index<&[usize]> for multidimensional array indexes, and get an excessive stack usage.

[Centril]

but I prefer to reduce expressiveness of things unless there’s a strong reason that expressiveness is required

I think this is a case of “I cannot tell the future”.

In this particular cases, I imagine that, with by-value DSTs implemented, someone might accidentally write Index<[usize]> instead of Index<&[usize]> for multidimensional array indexes, and get an excessive stack usage.

Seems lintable? We can test this out and see if it actually becomes a problem.