Unsized types allowed in trait method declarations and default type parameters

[apasel422]

It appears that the rules for where unsized types may appear are inconsistently enforced. This doesn't appear to cause unsoundness, because the items are unusable, but an early error would probably be helpful.

The following snippets compile with rustc 0.13.0-nightly (399ff259e 2014-11-20 00:27:07 +0000):

trait Foo {
    fn bar(a: [u8]);
    fn baz() -> [u8];
}

Attempting to implement Foo or provide a default implementation for bar or baz results in the expected compilation error per #13376.

#![feature(default_type_params)]
trait Foo<T = [u8]> {}
struct Bar<T = [u8]>;
enum Baz<T = [u8]> {}
fn quux<T = [u8]>() {}

Note that T is not declared Sized?. Attempting to explicitly instantiate this type parameter with an unsized type results in the expected compilation error for each of these cases.

[apasel422]

This is also the case for supertrait bounds:

trait Foo<T> {}
trait Bar : Foo<[u8]> {}

[apasel422]

This also compiles, though foo is not callable:

fn foo(_: [u8]) {}

[apasel422]

Another one (Vec's type parameter is sized):

type Foo = Vec<[u8]>;

[ftxqxd]

There are actually two issues here, as I see it:

1. Bounds on type parameters are not checked in many places. This includes default type parameters of functions and types (e.g., fn foo<T: Copy = Box<int>>()), supertrait parameters (e.g., trait Foo<T: Copy> {} trait Bar: Foo<Box<int>> {}), and type aliases (e.g., struct Foo<T: Copy>; type Bar = Foo<Box<int>>;). The case encountered in this issue is with Sized, which is an implicit bound on all type parameters that aren’t preceded by Sized?, but this actually applies to all trait bounds.
2. Unsized types are not disallowed in function parameter and return types (e.g., fn foo(_: [u8]) -> [u8]). This applies to trait methods, too.

Perhaps this issue should be split into two issues, then? I think this issue should be repurposed for the DST-related part (part 2), and a new issue should be created for the other part (unless such an issue already exists).

[arielb1]

@nikomatsakis claims this is intentional.

[arielb1]

closing.

[ibraheemdev]

@nikomatsakis Why is this intentional behavior? The following code still compiles on Rust 1.50:

trait Foo {
    fn bar(a: [u8]);
    fn baz() -> [u8];
}