Closed nikomatsakis closed 4 years ago
Feels like we should change the printout to complain about dyn Something: Sized
.
@arielb1 also true!
Any updates on this?
Nope, but I definitely think this is something we should do.
cc @withoutboats -- this is precisely the kind of bad Sized
error message we were talking about before. Any idea what you think it ought to say?
Its a pretty interesting case. Certainly Ariel's suggestion is a strict improvement:
= help: the trait `std::marker::Sized` is not implemented for `dyn Something`
The most common thing people do when they see the current error message, in my experience, is add a Sized
bound to trait Something
, which just digs them in deeper. Saying dyn Something
makes this a bit less likely, because they're more likely to see that the problem is with the object type and not the trait itself.
But the real problem here is that users don't realize that foo
requires T: Sized
, because you don't write out : Sized
explicitly.
Possibly the correct approach is to invert this error message for Sized
. With most traits, saying the type you instantiated with does not implement the trait is the helpful message. Here, the issue is that the function cannot take types like the one you passed.
I'm not great at error messages, but the idea I think we want to express is:
dyn Something
?Sized
typesT: ?Sized + Something
@withoutboats
But the real problem here is that users don't realize that foo requires
T: Sized
, because you don't write out: Sized
explicitly.
Hmm, yes. We can certainly try to dig in and offer some tips about the declaration site of T
, at least if it's crate-local.
Maybe just something like "note that the Sized
bound is implicit unless a type parameter is decorated with ?Sized
error[E0277]: the size for values of type `dyn Something` cannot be known at compilation time
--> src/main.rs:10:5
|
10 | foo(x);
| ^^^ doesn't have a size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `dyn Something`
= note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
note: required by `foo`
--> src/main.rs:6:1
|
6 | fn foo<T: Something>(_: &T) { }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Update:
error[E0277]: the size for values of type `dyn Something` cannot be known at compilation time
--> src/main.rs:10:9
|
6 | fn foo<T: Something>(_: &T) { }
| --- - required by this bound in `foo`
...
10 | foo(x);
| ^ doesn't have a size known at compile-time
|
= help: the trait `std::marker::Sized` is not implemented for `dyn Something`
= note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
I think this is a duplicate of https://github.com/rust-lang/rust/issues/57744.
Hi, I am very confused by this error message. I basically took the boilerplate code for cli_table and pasted it into my main fn:
use cli_table::{format::Justify, print_stdout, Cell, Style, Table};
let table = vec![
vec!["Tom".cell(), 10.cell().justify(Justify::Right)],
vec!["Jerry".cell(), 15.cell().justify(Justify::Right)],
vec!["Scooby Doo".cell(), 20.cell().justify(Justify::Right)],
]
.table()
.title(vec![
"Name".cell().bold(true),
"Age (in years)".cell().bold(true),
])
.bold(true);
assert!(print_stdout(table).is_ok());
Cool. This works, but now I want make a separate function that returns the Table and just call the final print function from main.
So I have a function that returns cli_table's Table
:
pub fn render_table() -> Table {
Then the compile tells me I need to add dyn
to table so I do that, but then it complains that my function render_table "doesn't have a size known at compile-time".
So then I put the Table
in a Box
and return that:
pub fn render_table() -> Box<dyn Table> {
But now back main I can't just call this and use it like it's a table...
let table = render_table();
assert!(print_stdout(table).is_ok());
gives me the error:
error[E0277]: `dyn Table` is not an iterator
--> src/bin/table_of_chairs/main.rs:11:26
|
11 | assert!(print_stdout(table).is_ok());
| ------------ ^^^^^ `dyn Table` is not an iterator
| |
| required by a bound introduced by this call
|
= help: the trait `Iterator` is not implemented for `dyn Table`
= help: the trait `Table` is implemented for `TableStruct`
= note: required for `Box<dyn Table>` to implement `Iterator`
= note: required for `Box<dyn Table>` to implement `Table`
note: required by a bound in `print_stdout`
So I need to I guess "unbox" the Table now?
This section of Rust by Example starts talking about it but doesn't mention at all how to actually use the Boxed Animal... 🥲
From this section of Easy Rust it says I should be able to use the star character to "deref the box back to the Trait", but when I do that I get the original "no size at compile time error" 😭
let table = render_table();
assert!(print_stdout(*table).is_ok());
error[E0277]: the size for values of type `dyn Table` cannot be known at compilation time
--> src/bin/table_of_chairs/main.rs:11:26
|
11 | assert!(print_stdout(*table).is_ok());
| ------------ ^^^^^^ doesn't have a size known at compile-time
| |
| required by a bound introduced by this call
|
= help: the trait `Sized` is not implemented for `dyn Table`
note: required by a bound in `print_stdout`
UPDATE - ok, after all that I realized that there was actually another Trait exported from the third party crate that I should have been using the whole time... TableStruct
🤦♂️
@JimLynchCodes feel free to create new tickets for these kind of issues. Sadly we are aware of the sorry state of some trait bound errors, having examples for them is useful because they help us 1) track their change over time and 2) we might be able to fix a "family" of issues when we notice patterns. For a case like this one, where importing a trait from a crate the compiler knows about is the solution, then rustc
should be giving you that hint. The compiler should always give you enough context to solve the issue, and I'd argue that it didn't here. Would you mind filing a new ticket with all of the information in your ticket? I can't assure that we will fix it soon, but having it in our backlog will give us a chance to do so at some point.
The error that you get when using a
dyn
type with a fn that expects aSized
type parameter is not particularly enlightening:yields:
This came up when attempting to do some refactorings to use a
dyn Trait
where previously we had used a type parameter. I'm not exactly sure what sort of error we should report here -- but it seems like it'd be nice to talk about the definition site.