]> git.lizzy.rs Git - rust.git/blob - src/libcore/marker.rs
Auto merge of #29454 - stepancheg:vec-reserve, r=bluss
[rust.git] / src / libcore / marker.rs
1 // Copyright 2012-2015 The Rust Project Developers. See the COPYRIGHT
2 // file at the top-level directory of this distribution and at
3 // http://rust-lang.org/COPYRIGHT.
4 //
5 // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
6 // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
7 // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
8 // option. This file may not be copied, modified, or distributed
9 // except according to those terms.
10
11 //! Primitive traits and marker types representing basic 'kinds' of types.
12 //!
13 //! Rust types can be classified in various useful ways according to
14 //! intrinsic properties of the type. These classifications, often called
15 //! 'kinds', are represented as traits.
16
17 #![stable(feature = "rust1", since = "1.0.0")]
18
19 use clone::Clone;
20 use cmp;
21 use default::Default;
22 use option::Option;
23 use hash::Hash;
24 use hash::Hasher;
25
26 /// Types able to be transferred across thread boundaries.
27 #[stable(feature = "rust1", since = "1.0.0")]
28 #[lang = "send"]
29 #[rustc_on_unimplemented = "`{Self}` cannot be sent between threads safely"]
30 pub unsafe trait Send {
31     // empty.
32 }
33
34 unsafe impl Send for .. { }
35
36 impl<T> !Send for *const T { }
37 impl<T> !Send for *mut T { }
38
39 /// Types with a constant size known at compile-time.
40 ///
41 /// All type parameters which can be bounded have an implicit bound of `Sized`. The special syntax
42 /// `?Sized` can be used to remove this bound if it is not appropriate.
43 ///
44 /// ```
45 /// struct Foo<T>(T);
46 /// struct Bar<T: ?Sized>(T);
47 ///
48 /// // struct FooUse(Foo<[i32]>); // error: Sized is not implemented for [i32]
49 /// struct BarUse(Bar<[i32]>); // OK
50 /// ```
51 #[stable(feature = "rust1", since = "1.0.0")]
52 #[lang = "sized"]
53 #[rustc_on_unimplemented = "`{Self}` does not have a constant size known at compile-time"]
54 #[fundamental] // for Default, for example, which requires that `[T]: !Default` be evaluatable
55 pub trait Sized {
56     // Empty.
57 }
58
59 /// Types that can be "unsized" to a dynamically sized type.
60 #[unstable(feature = "unsize", issue = "27732")]
61 #[lang="unsize"]
62 pub trait Unsize<T: ?Sized> {
63     // Empty.
64 }
65
66 /// Types that can be copied by simply copying bits (i.e. `memcpy`).
67 ///
68 /// By default, variable bindings have 'move semantics.' In other
69 /// words:
70 ///
71 /// ```
72 /// #[derive(Debug)]
73 /// struct Foo;
74 ///
75 /// let x = Foo;
76 ///
77 /// let y = x;
78 ///
79 /// // `x` has moved into `y`, and so cannot be used
80 ///
81 /// // println!("{:?}", x); // error: use of moved value
82 /// ```
83 ///
84 /// However, if a type implements `Copy`, it instead has 'copy semantics':
85 ///
86 /// ```
87 /// // we can just derive a `Copy` implementation
88 /// #[derive(Debug, Copy, Clone)]
89 /// struct Foo;
90 ///
91 /// let x = Foo;
92 ///
93 /// let y = x;
94 ///
95 /// // `y` is a copy of `x`
96 ///
97 /// println!("{:?}", x); // A-OK!
98 /// ```
99 ///
100 /// It's important to note that in these two examples, the only difference is if you are allowed to
101 /// access `x` after the assignment: a move is also a bitwise copy under the hood.
102 ///
103 /// ## When can my type be `Copy`?
104 ///
105 /// A type can implement `Copy` if all of its components implement `Copy`. For example, this
106 /// `struct` can be `Copy`:
107 ///
108 /// ```
109 /// struct Point {
110 ///    x: i32,
111 ///    y: i32,
112 /// }
113 /// ```
114 ///
115 /// A `struct` can be `Copy`, and `i32` is `Copy`, so therefore, `Point` is eligible to be `Copy`.
116 ///
117 /// ```
118 /// # struct Point;
119 /// struct PointList {
120 ///     points: Vec<Point>,
121 /// }
122 /// ```
123 ///
124 /// The `PointList` `struct` cannot implement `Copy`, because `Vec<T>` is not `Copy`. If we
125 /// attempt to derive a `Copy` implementation, we'll get an error:
126 ///
127 /// ```text
128 /// the trait `Copy` may not be implemented for this type; field `points` does not implement `Copy`
129 /// ```
130 ///
131 /// ## How can I implement `Copy`?
132 ///
133 /// There are two ways to implement `Copy` on your type:
134 ///
135 /// ```
136 /// #[derive(Copy, Clone)]
137 /// struct MyStruct;
138 /// ```
139 ///
140 /// and
141 ///
142 /// ```
143 /// struct MyStruct;
144 /// impl Copy for MyStruct {}
145 /// impl Clone for MyStruct { fn clone(&self) -> MyStruct { *self } }
146 /// ```
147 ///
148 /// There is a small difference between the two: the `derive` strategy will also place a `Copy`
149 /// bound on type parameters, which isn't always desired.
150 ///
151 /// ## When can my type _not_ be `Copy`?
152 ///
153 /// Some types can't be copied safely. For example, copying `&mut T` would create an aliased
154 /// mutable reference, and copying `String` would result in two attempts to free the same buffer.
155 ///
156 /// Generalizing the latter case, any type implementing `Drop` can't be `Copy`, because it's
157 /// managing some resource besides its own `size_of::<T>()` bytes.
158 ///
159 /// ## When should my type be `Copy`?
160 ///
161 /// Generally speaking, if your type _can_ implement `Copy`, it should. There's one important thing
162 /// to consider though: if you think your type may _not_ be able to implement `Copy` in the future,
163 /// then it might be prudent to not implement `Copy`. This is because removing `Copy` is a breaking
164 /// change: that second example would fail to compile if we made `Foo` non-`Copy`.
165 #[stable(feature = "rust1", since = "1.0.0")]
166 #[lang = "copy"]
167 pub trait Copy : Clone {
168     // Empty.
169 }
170
171 /// Types that can be safely shared between threads when aliased.
172 ///
173 /// The precise definition is: a type `T` is `Sync` if `&T` is
174 /// thread-safe. In other words, there is no possibility of data races
175 /// when passing `&T` references between threads.
176 ///
177 /// As one would expect, primitive types like `u8` and `f64` are all
178 /// `Sync`, and so are simple aggregate types containing them (like
179 /// tuples, structs and enums). More instances of basic `Sync` types
180 /// include "immutable" types like `&T` and those with simple
181 /// inherited mutability, such as `Box<T>`, `Vec<T>` and most other
182 /// collection types. (Generic parameters need to be `Sync` for their
183 /// container to be `Sync`.)
184 ///
185 /// A somewhat surprising consequence of the definition is `&mut T` is
186 /// `Sync` (if `T` is `Sync`) even though it seems that it might
187 /// provide unsynchronized mutation. The trick is a mutable reference
188 /// stored in an aliasable reference (that is, `& &mut T`) becomes
189 /// read-only, as if it were a `& &T`, hence there is no risk of a data
190 /// race.
191 ///
192 /// Types that are not `Sync` are those that have "interior
193 /// mutability" in a non-thread-safe way, such as `Cell` and `RefCell`
194 /// in `std::cell`. These types allow for mutation of their contents
195 /// even when in an immutable, aliasable slot, e.g. the contents of
196 /// `&Cell<T>` can be `.set`, and do not ensure data races are
197 /// impossible, hence they cannot be `Sync`. A higher level example
198 /// of a non-`Sync` type is the reference counted pointer
199 /// `std::rc::Rc`, because any reference `&Rc<T>` can clone a new
200 /// reference, which modifies the reference counts in a non-atomic
201 /// way.
202 ///
203 /// For cases when one does need thread-safe interior mutability,
204 /// types like the atomics in `std::sync` and `Mutex` & `RWLock` in
205 /// the `sync` crate do ensure that any mutation cannot cause data
206 /// races.  Hence these types are `Sync`.
207 ///
208 /// Any types with interior mutability must also use the `std::cell::UnsafeCell`
209 /// wrapper around the value(s) which can be mutated when behind a `&`
210 /// reference; not doing this is undefined behavior (for example,
211 /// `transmute`-ing from `&T` to `&mut T` is invalid).
212 #[stable(feature = "rust1", since = "1.0.0")]
213 #[lang = "sync"]
214 #[rustc_on_unimplemented = "`{Self}` cannot be shared between threads safely"]
215 pub unsafe trait Sync {
216     // Empty
217 }
218
219 unsafe impl Sync for .. { }
220
221 impl<T> !Sync for *const T { }
222 impl<T> !Sync for *mut T { }
223
224 macro_rules! impls{
225     ($t: ident) => (
226         impl<T:?Sized> Hash for $t<T> {
227             #[inline]
228             fn hash<H: Hasher>(&self, _: &mut H) {
229             }
230         }
231
232         impl<T:?Sized> cmp::PartialEq for $t<T> {
233             fn eq(&self, _other: &$t<T>) -> bool {
234                 true
235             }
236         }
237
238         impl<T:?Sized> cmp::Eq for $t<T> {
239         }
240
241         impl<T:?Sized> cmp::PartialOrd for $t<T> {
242             fn partial_cmp(&self, _other: &$t<T>) -> Option<cmp::Ordering> {
243                 Option::Some(cmp::Ordering::Equal)
244             }
245         }
246
247         impl<T:?Sized> cmp::Ord for $t<T> {
248             fn cmp(&self, _other: &$t<T>) -> cmp::Ordering {
249                 cmp::Ordering::Equal
250             }
251         }
252
253         impl<T:?Sized> Copy for $t<T> { }
254
255         impl<T:?Sized> Clone for $t<T> {
256             fn clone(&self) -> $t<T> {
257                 $t
258             }
259         }
260
261         impl<T:?Sized> Default for $t<T> {
262             fn default() -> $t<T> {
263                 $t
264             }
265         }
266         )
267 }
268
269 /// `PhantomData<T>` allows you to describe that a type acts as if it stores a value of type `T`,
270 /// even though it does not. This allows you to inform the compiler about certain safety properties
271 /// of your code.
272 ///
273 /// # A ghastly note ðŸ‘»ðŸ‘»ðŸ‘»
274 ///
275 /// Though they both have scary names, `PhantomData<T>` and 'phantom types' are related, but not
276 /// identical. Phantom types are a more general concept that don't require `PhantomData<T>` to
277 /// implement, but `PhantomData<T>` is the most common way to implement them in a correct manner.
278 ///
279 /// # Examples
280 ///
281 /// ## Unused lifetime parameter
282 ///
283 /// Perhaps the most common time that `PhantomData` is required is
284 /// with a struct that has an unused lifetime parameter, typically as
285 /// part of some unsafe code. For example, here is a struct `Slice`
286 /// that has two pointers of type `*const T`, presumably pointing into
287 /// an array somewhere:
288 ///
289 /// ```ignore
290 /// struct Slice<'a, T> {
291 ///     start: *const T,
292 ///     end: *const T,
293 /// }
294 /// ```
295 ///
296 /// The intention is that the underlying data is only valid for the
297 /// lifetime `'a`, so `Slice` should not outlive `'a`. However, this
298 /// intent is not expressed in the code, since there are no uses of
299 /// the lifetime `'a` and hence it is not clear what data it applies
300 /// to. We can correct this by telling the compiler to act *as if* the
301 /// `Slice` struct contained a borrowed reference `&'a T`:
302 ///
303 /// ```
304 /// use std::marker::PhantomData;
305 ///
306 /// struct Slice<'a, T:'a> {
307 ///     start: *const T,
308 ///     end: *const T,
309 ///     phantom: PhantomData<&'a T>
310 /// }
311 /// ```
312 ///
313 /// This also in turn requires that we annotate `T:'a`, indicating
314 /// that `T` is a type that can be borrowed for the lifetime `'a`.
315 ///
316 /// ## Unused type parameters
317 ///
318 /// It sometimes happens that there are unused type parameters that
319 /// indicate what type of data a struct is "tied" to, even though that
320 /// data is not actually found in the struct itself. Here is an
321 /// example where this arises when handling external resources over a
322 /// foreign function interface. `PhantomData<T>` can prevent
323 /// mismatches by enforcing types in the method implementations:
324 ///
325 /// ```
326 /// # trait ResType { fn foo(&self); }
327 /// # struct ParamType;
328 /// # mod foreign_lib {
329 /// # pub fn new(_: usize) -> *mut () { 42 as *mut () }
330 /// # pub fn do_stuff(_: *mut (), _: usize) {}
331 /// # }
332 /// # fn convert_params(_: ParamType) -> usize { 42 }
333 /// use std::marker::PhantomData;
334 /// use std::mem;
335 ///
336 /// struct ExternalResource<R> {
337 ///    resource_handle: *mut (),
338 ///    resource_type: PhantomData<R>,
339 /// }
340 ///
341 /// impl<R: ResType> ExternalResource<R> {
342 ///     fn new() -> ExternalResource<R> {
343 ///         let size_of_res = mem::size_of::<R>();
344 ///         ExternalResource {
345 ///             resource_handle: foreign_lib::new(size_of_res),
346 ///             resource_type: PhantomData,
347 ///         }
348 ///     }
349 ///
350 ///     fn do_stuff(&self, param: ParamType) {
351 ///         let foreign_params = convert_params(param);
352 ///         foreign_lib::do_stuff(self.resource_handle, foreign_params);
353 ///     }
354 /// }
355 /// ```
356 ///
357 /// ## Indicating ownership
358 ///
359 /// Adding a field of type `PhantomData<T>` also indicates that your
360 /// struct owns data of type `T`. This in turn implies that when your
361 /// struct is dropped, it may in turn drop one or more instances of
362 /// the type `T`, though that may not be apparent from the other
363 /// structure of the type itself. This is commonly necessary if the
364 /// structure is using a raw pointer like `*mut T` whose referent
365 /// may be dropped when the type is dropped, as a `*mut T` is
366 /// otherwise not treated as owned.
367 ///
368 /// If your struct does not in fact *own* the data of type `T`, it is
369 /// better to use a reference type, like `PhantomData<&'a T>`
370 /// (ideally) or `PhantomData<*const T>` (if no lifetime applies), so
371 /// as not to indicate ownership.
372 #[lang = "phantom_data"]
373 #[stable(feature = "rust1", since = "1.0.0")]
374 pub struct PhantomData<T:?Sized>;
375
376 impls! { PhantomData }
377
378 mod impls {
379     use super::{Send, Sync, Sized};
380
381     unsafe impl<'a, T: Sync + ?Sized> Send for &'a T {}
382     unsafe impl<'a, T: Send + ?Sized> Send for &'a mut T {}
383 }
384
385 /// A marker trait indicates a type that can be reflected over. This
386 /// trait is implemented for all types. Its purpose is to ensure that
387 /// when you write a generic function that will employ reflection,
388 /// that must be reflected (no pun intended) in the generic bounds of
389 /// that function. Here is an example:
390 ///
391 /// ```
392 /// #![feature(reflect_marker)]
393 /// use std::marker::Reflect;
394 /// use std::any::Any;
395 /// fn foo<T:Reflect+'static>(x: &T) {
396 ///     let any: &Any = x;
397 ///     if any.is::<u32>() { println!("u32"); }
398 /// }
399 /// ```
400 ///
401 /// Without the declaration `T:Reflect`, `foo` would not type check
402 /// (note: as a matter of style, it would be preferable to write
403 /// `T:Any`, because `T:Any` implies `T:Reflect` and `T:'static`, but
404 /// we use `Reflect` here to show how it works). The `Reflect` bound
405 /// thus serves to alert `foo`'s caller to the fact that `foo` may
406 /// behave differently depending on whether `T=u32` or not. In
407 /// particular, thanks to the `Reflect` bound, callers know that a
408 /// function declared like `fn bar<T>(...)` will always act in
409 /// precisely the same way no matter what type `T` is supplied,
410 /// because there are no bounds declared on `T`. (The ability for a
411 /// caller to reason about what a function may do based solely on what
412 /// generic bounds are declared is often called the ["parametricity
413 /// property"][1].)
414 ///
415 /// [1]: http://en.wikipedia.org/wiki/Parametricity
416 #[rustc_reflect_like]
417 #[unstable(feature = "reflect_marker",
418            reason = "requires RFC and more experience",
419            issue = "27749")]
420 #[rustc_on_unimplemented = "`{Self}` does not implement `Any`; \
421                             ensure all type parameters are bounded by `Any`"]
422 pub trait Reflect {}
423
424 impl Reflect for .. { }