From: Ralf Jung Date: Fri, 16 Sep 2016 06:53:44 +0000 (+0200) Subject: Merge pull request #21 from avkrotov/implemenets X-Git-Url: https://git.ralfj.de/rust-101.git/commitdiff_plain/0c5e5d86510258f57cf2c1f23479b675e14c50d3?hp=a910b7951064783570a2a759340ca8951d20a9a1 Merge pull request #21 from avkrotov/implemenets s/implemenets/implements/ --- diff --git a/src/part11.rs b/src/part11.rs index 9d931db..5134401 100644 --- a/src/part11.rs +++ b/src/part11.rs @@ -23,7 +23,7 @@ struct CallbacksV1 { //@ But, Rust complains about this definition. It says something about "Sized". What's the trouble? See, for many things we want to do, it is crucial that //@ Rust knows the precise, fixed size of the type - that is, how large this type will be when represented in memory. For example, for a `Vec`, the //@ elements are stored one right after the other. How should that be possible, without a fixed size? The point is, `FnMut(i32)` could be of any size. -//@ We don't know how large that "type that implemenets `FnMut(i32)`" is. Rust calls this an *unsized* type. Whenever we introduce a type variable, Rust +//@ We don't know how large that "type that implements `FnMut(i32)`" is. Rust calls this an *unsized* type. Whenever we introduce a type variable, Rust //@ will implicitly add a bound to that variable, demanding that it is sized. That's why we did not have to worry about this so far.
//@ You can opt-out of this implicit bound by saying `T: ?Sized`. Then `T` may or may not be sized.