1 #[doc(primitive = "bool")]
3 #[doc(alias = "false")]
7 /// The `bool` represents a value, which could only be either `true` or `false`. If you cast
8 /// a `bool` into an integer, `true` will be 1 and `false` will be 0.
12 /// `bool` implements various traits, such as [`BitAnd`], [`BitOr`], [`Not`], etc.,
13 /// which allow us to perform boolean operations using `&`, `|` and `!`.
15 /// `if` always demands a `bool` value. [`assert!`], being an important macro in testing,
16 /// checks whether an expression returns `true`.
19 /// let bool_val = true & false | false;
20 /// assert!(!bool_val);
23 /// [`assert!`]: macro.assert.html
24 /// [`BitAnd`]: ops/trait.BitAnd.html
25 /// [`BitOr`]: ops/trait.BitOr.html
26 /// [`Not`]: ops/trait.Not.html
30 /// A trivial example of the usage of `bool`,
33 /// let praise_the_borrow_checker = true;
35 /// // using the `if` conditional
36 /// if praise_the_borrow_checker {
37 /// println!("oh, yeah!");
39 /// println!("what?!!");
42 /// // ... or, a match pattern
43 /// match praise_the_borrow_checker {
44 /// true => println!("keep praising!"),
45 /// false => println!("you should praise!"),
49 /// Also, since `bool` implements the [`Copy`](marker/trait.Copy.html) trait, we don't
50 /// have to worry about the move semantics (just like the integer and float primitives).
52 /// Now an example of `bool` cast to integer type:
55 /// assert_eq!(true as i32, 1);
56 /// assert_eq!(false as i32, 0);
58 #[stable(feature = "rust1", since = "1.0.0")]
61 #[doc(primitive = "never")]
64 /// The `!` type, also called "never".
66 /// `!` represents the type of computations which never resolve to any value at all. For example,
67 /// the [`exit`] function `fn exit(code: i32) -> !` exits the process without ever returning, and
70 /// `break`, `continue` and `return` expressions also have type `!`. For example we are allowed to
74 /// #![feature(never_type)]
75 /// # fn foo() -> u32 {
82 /// Although the `let` is pointless here, it illustrates the meaning of `!`. Since `x` is never
83 /// assigned a value (because `return` returns from the entire function), `x` can be given type
84 /// `!`. We could also replace `return 123` with a `panic!` or a never-ending `loop` and this code
85 /// would still be valid.
87 /// A more realistic usage of `!` is in this code:
90 /// # fn get_a_number() -> Option<u32> { None }
92 /// let num: u32 = match get_a_number() {
99 /// Both match arms must produce values of type [`u32`], but since `break` never produces a value
100 /// at all we know it can never produce a value which isn't a [`u32`]. This illustrates another
101 /// behaviour of the `!` type - expressions with type `!` will coerce into any other type.
103 /// [`u32`]: primitive.str.html
104 /// [`exit`]: process/fn.exit.html
106 /// # `!` and generics
108 /// ## Infallible errors
110 /// The main place you'll see `!` used explicitly is in generic code. Consider the [`FromStr`]
114 /// trait FromStr: Sized {
116 /// fn from_str(s: &str) -> Result<Self, Self::Err>;
120 /// When implementing this trait for [`String`] we need to pick a type for [`Err`]. And since
121 /// converting a string into a string will never result in an error, the appropriate type is `!`.
122 /// (Currently the type actually used is an enum with no variants, though this is only because `!`
123 /// was added to Rust at a later date and it may change in the future.) With an [`Err`] type of
124 /// `!`, if we have to call [`String::from_str`] for some reason the result will be a
125 /// [`Result<String, !>`] which we can unpack like this:
127 /// ```ignore (string-from-str-error-type-is-not-never-yet)
128 /// #[feature(exhaustive_patterns)]
129 /// // NOTE: this does not work today!
130 /// let Ok(s) = String::from_str("hello");
133 /// Since the [`Err`] variant contains a `!`, it can never occur. If the `exhaustive_patterns`
134 /// feature is present this means we can exhaustively match on [`Result<T, !>`] by just taking the
135 /// [`Ok`] variant. This illustrates another behaviour of `!` - it can be used to "delete" certain
136 /// enum variants from generic types like `Result`.
138 /// ## Infinite loops
140 /// While [`Result<T, !>`] is very useful for removing errors, `!` can also be used to remove
141 /// successes as well. If we think of [`Result<T, !>`] as "if this function returns, it has not
142 /// errored," we get a very intuitive idea of [`Result<!, E>`] as well: if the function returns, it
145 /// For example, consider the case of a simple web server, which can be simplified to:
147 /// ```ignore (hypothetical-example)
149 /// let (client, request) = get_request().expect("disconnected");
150 /// let response = request.process();
151 /// response.send(client);
155 /// Currently, this isn't ideal, because we simply panic whenever we fail to get a new connection.
156 /// Instead, we'd like to keep track of this error, like this:
158 /// ```ignore (hypothetical-example)
160 /// match get_request() {
161 /// Err(err) => break err,
162 /// Ok((client, request)) => {
163 /// let response = request.process();
164 /// response.send(client);
170 /// Now, when the server disconnects, we exit the loop with an error instead of panicking. While it
171 /// might be intuitive to simply return the error, we might want to wrap it in a [`Result<!, E>`]
174 /// ```ignore (hypothetical-example)
175 /// fn server_loop() -> Result<!, ConnectionError> {
177 /// let (client, request) = get_request()?;
178 /// let response = request.process();
179 /// response.send(client);
184 /// Now, we can use `?` instead of `match`, and the return type makes a lot more sense: if the loop
185 /// ever stops, it means that an error occurred. We don't even have to wrap the loop in an `Ok`
186 /// because `!` coerces to `Result<!, ConnectionError>` automatically.
188 /// [`String::from_str`]: str/trait.FromStr.html#tymethod.from_str
189 /// [`Result<String, !>`]: result/enum.Result.html
190 /// [`Result<T, !>`]: result/enum.Result.html
191 /// [`Result<!, E>`]: result/enum.Result.html
192 /// [`Ok`]: result/enum.Result.html#variant.Ok
193 /// [`String`]: string/struct.String.html
194 /// [`Err`]: result/enum.Result.html#variant.Err
195 /// [`FromStr`]: str/trait.FromStr.html
199 /// When writing your own traits, `!` should have an `impl` whenever there is an obvious `impl`
200 /// which doesn't `panic!`. As it turns out, most traits can have an `impl` for `!`. Take [`Debug`]
204 /// #![feature(never_type)]
207 /// # fn fmt(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result;
209 /// impl Debug for ! {
210 /// fn fmt(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result {
216 /// Once again we're using `!`'s ability to coerce into any other type, in this case
217 /// [`fmt::Result`]. Since this method takes a `&!` as an argument we know that it can never be
218 /// called (because there is no value of type `!` for it to be called with). Writing `*self`
219 /// essentially tells the compiler "We know that this code can never be run, so just treat the
220 /// entire function body as having type [`fmt::Result`]". This pattern can be used a lot when
221 /// implementing traits for `!`. Generally, any trait which only has methods which take a `self`
222 /// parameter should have such an impl.
224 /// On the other hand, one trait which would not be appropriate to implement is [`Default`]:
228 /// fn default() -> Self;
232 /// Since `!` has no values, it has no default value either. It's true that we could write an
233 /// `impl` for this which simply panics, but the same is true for any type (we could `impl
234 /// Default` for (eg.) [`File`] by just making [`default()`] panic.)
236 /// [`fmt::Result`]: fmt/type.Result.html
237 /// [`File`]: fs/struct.File.html
238 /// [`Debug`]: fmt/trait.Debug.html
239 /// [`Default`]: default/trait.Default.html
240 /// [`default()`]: default/trait.Default.html#tymethod.default
242 #[unstable(feature = "never_type", issue = "35121")]
245 #[doc(primitive = "char")]
247 /// A character type.
249 /// The `char` type represents a single character. More specifically, since
250 /// 'character' isn't a well-defined concept in Unicode, `char` is a '[Unicode
251 /// scalar value]', which is similar to, but not the same as, a '[Unicode code
254 /// [Unicode scalar value]: http://www.unicode.org/glossary/#unicode_scalar_value
255 /// [Unicode code point]: http://www.unicode.org/glossary/#code_point
257 /// This documentation describes a number of methods and trait implementations on the
258 /// `char` type. For technical reasons, there is additional, separate
259 /// documentation in [the `std::char` module](char/index.html) as well.
263 /// `char` is always four bytes in size. This is a different representation than
264 /// a given character would have as part of a [`String`]. For example:
267 /// let v = vec!['h', 'e', 'l', 'l', 'o'];
269 /// // five elements times four bytes for each element
270 /// assert_eq!(20, v.len() * std::mem::size_of::<char>());
272 /// let s = String::from("hello");
274 /// // five elements times one byte per element
275 /// assert_eq!(5, s.len() * std::mem::size_of::<u8>());
278 /// [`String`]: string/struct.String.html
280 /// As always, remember that a human intuition for 'character' may not map to
281 /// Unicode's definitions. For example, despite looking similar, the 'é'
282 /// character is one Unicode code point while 'é' is two Unicode code points:
285 /// let mut chars = "é".chars();
286 /// // U+00e9: 'latin small letter e with acute'
287 /// assert_eq!(Some('\u{00e9}'), chars.next());
288 /// assert_eq!(None, chars.next());
290 /// let mut chars = "é".chars();
291 /// // U+0065: 'latin small letter e'
292 /// assert_eq!(Some('\u{0065}'), chars.next());
293 /// // U+0301: 'combining acute accent'
294 /// assert_eq!(Some('\u{0301}'), chars.next());
295 /// assert_eq!(None, chars.next());
298 /// This means that the contents of the first string above _will_ fit into a
299 /// `char` while the contents of the second string _will not_. Trying to create
300 /// a `char` literal with the contents of the second string gives an error:
303 /// error: character literal may only contain one codepoint: 'é'
308 /// Another implication of the 4-byte fixed size of a `char` is that
309 /// per-`char` processing can end up using a lot more memory:
312 /// let s = String::from("love: ❤️");
313 /// let v: Vec<char> = s.chars().collect();
315 /// assert_eq!(12, std::mem::size_of_val(&s[..]));
316 /// assert_eq!(32, std::mem::size_of_val(&v[..]));
318 #[stable(feature = "rust1", since = "1.0.0")]
321 #[doc(primitive = "unit")]
323 /// The `()` type, also called "unit".
325 /// The `()` type has exactly one value `()`, and is used when there
326 /// is no other meaningful value that could be returned. `()` is most
327 /// commonly seen implicitly: functions without a `-> ...` implicitly
328 /// have return type `()`, that is, these are equivalent:
331 /// fn long() -> () {}
336 /// The semicolon `;` can be used to discard the result of an
337 /// expression at the end of a block, making the expression (and thus
338 /// the block) evaluate to `()`. For example,
341 /// fn returns_i64() -> i64 {
344 /// fn returns_unit() {
356 #[stable(feature = "rust1", since = "1.0.0")]
359 #[doc(primitive = "pointer")]
361 /// Raw, unsafe pointers, `*const T`, and `*mut T`.
363 /// *[See also the `std::ptr` module](ptr/index.html).*
365 /// Working with raw pointers in Rust is uncommon, typically limited to a few patterns.
366 /// Raw pointers can be unaligned or [`null`]. However, when a raw pointer is
367 /// dereferenced (using the `*` operator), it must be non-null and aligned.
369 /// Storing through a raw pointer using `*ptr = data` calls `drop` on the old value, so
370 /// [`write`] must be used if the type has drop glue and memory is not already
371 /// initialized - otherwise `drop` would be called on the uninitialized memory.
373 /// Use the [`null`] and [`null_mut`] functions to create null pointers, and the
374 /// [`is_null`] method of the `*const T` and `*mut T` types to check for null.
375 /// The `*const T` and `*mut T` types also define the [`offset`] method, for
378 /// # Common ways to create raw pointers
380 /// ## 1. Coerce a reference (`&T`) or mutable reference (`&mut T`).
383 /// let my_num: i32 = 10;
384 /// let my_num_ptr: *const i32 = &my_num;
385 /// let mut my_speed: i32 = 88;
386 /// let my_speed_ptr: *mut i32 = &mut my_speed;
389 /// To get a pointer to a boxed value, dereference the box:
392 /// let my_num: Box<i32> = Box::new(10);
393 /// let my_num_ptr: *const i32 = &*my_num;
394 /// let mut my_speed: Box<i32> = Box::new(88);
395 /// let my_speed_ptr: *mut i32 = &mut *my_speed;
398 /// This does not take ownership of the original allocation
399 /// and requires no resource management later,
400 /// but you must not use the pointer after its lifetime.
402 /// ## 2. Consume a box (`Box<T>`).
404 /// The [`into_raw`] function consumes a box and returns
405 /// the raw pointer. It doesn't destroy `T` or deallocate any memory.
408 /// let my_speed: Box<i32> = Box::new(88);
409 /// let my_speed: *mut i32 = Box::into_raw(my_speed);
411 /// // By taking ownership of the original `Box<T>` though
412 /// // we are obligated to put it together later to be destroyed.
414 /// drop(Box::from_raw(my_speed));
418 /// Note that here the call to [`drop`] is for clarity - it indicates
419 /// that we are done with the given value and it should be destroyed.
421 /// ## 3. Get it from C.
424 /// # #![feature(rustc_private)]
425 /// extern crate libc;
430 /// let my_num: *mut i32 = libc::malloc(mem::size_of::<i32>()) as *mut i32;
431 /// if my_num.is_null() {
432 /// panic!("failed to allocate memory");
434 /// libc::free(my_num as *mut libc::c_void);
438 /// Usually you wouldn't literally use `malloc` and `free` from Rust,
439 /// but C APIs hand out a lot of pointers generally, so are a common source
440 /// of raw pointers in Rust.
442 /// [`null`]: ../std/ptr/fn.null.html
443 /// [`null_mut`]: ../std/ptr/fn.null_mut.html
444 /// [`is_null`]: ../std/primitive.pointer.html#method.is_null
445 /// [`offset`]: ../std/primitive.pointer.html#method.offset
446 /// [`into_raw`]: ../std/boxed/struct.Box.html#method.into_raw
447 /// [`drop`]: ../std/mem/fn.drop.html
448 /// [`write`]: ../std/ptr/fn.write.html
449 #[stable(feature = "rust1", since = "1.0.0")]
452 #[doc(primitive = "array")]
454 /// A fixed-size array, denoted `[T; N]`, for the element type, `T`, and the
455 /// non-negative compile-time constant size, `N`.
457 /// There are two syntactic forms for creating an array:
459 /// * A list with each element, i.e., `[x, y, z]`.
460 /// * A repeat expression `[x; N]`, which produces an array with `N` copies of `x`.
461 /// The type of `x` must be [`Copy`][copy].
463 /// Arrays of *any* size implement the following traits if the element type allows it:
465 /// - [`Debug`][debug]
466 /// - [`IntoIterator`][intoiterator] (implemented for `&[T; N]` and `&mut [T; N]`)
467 /// - [`PartialEq`][partialeq], [`PartialOrd`][partialord], [`Eq`][eq], [`Ord`][ord]
469 /// - [`AsRef`][asref], [`AsMut`][asmut]
470 /// - [`Borrow`][borrow], [`BorrowMut`][borrowmut]
472 /// Arrays of sizes from 0 to 32 (inclusive) implement [`Default`][default] trait
473 /// if the element type allows it. As a stopgap, trait implementations are
474 /// statically generated up to size 32.
476 /// Arrays of *any* size are [`Copy`][copy] if the element type is [`Copy`][copy]
477 /// and [`Clone`][clone] if the element type is [`Clone`][clone]. This works
478 /// because [`Copy`][copy] and [`Clone`][clone] traits are specially known
481 /// Arrays coerce to [slices (`[T]`)][slice], so a slice method may be called on
482 /// an array. Indeed, this provides most of the API for working with arrays.
483 /// Slices have a dynamic size and do not coerce to arrays.
485 /// You can move elements out of an array with a slice pattern. If you want
486 /// one element, see [`mem::replace`][replace].
491 /// let mut array: [i32; 3] = [0; 3];
496 /// assert_eq!([1, 2], &array[1..]);
498 /// // This loop prints: 0 1 2
499 /// for x in &array {
500 /// print!("{} ", x);
504 /// An array itself is not iterable:
506 /// ```compile_fail,E0277
507 /// let array: [i32; 3] = [0; 3];
509 /// for x in array { }
510 /// // error: the trait bound `[i32; 3]: std::iter::Iterator` is not satisfied
513 /// The solution is to coerce the array to a slice by calling a slice method:
516 /// # let array: [i32; 3] = [0; 3];
517 /// for x in array.iter() { }
520 /// You can also use the array reference's [`IntoIterator`] implementation:
523 /// # let array: [i32; 3] = [0; 3];
524 /// for x in &array { }
527 /// You can use a slice pattern to move elements out of an array:
530 /// fn move_away(_: String) { /* Do interesting things. */ }
532 /// let [john, roa] = ["John".to_string(), "Roa".to_string()];
537 /// [slice]: primitive.slice.html
538 /// [copy]: marker/trait.Copy.html
539 /// [clone]: clone/trait.Clone.html
540 /// [debug]: fmt/trait.Debug.html
541 /// [intoiterator]: iter/trait.IntoIterator.html
542 /// [partialeq]: cmp/trait.PartialEq.html
543 /// [partialord]: cmp/trait.PartialOrd.html
544 /// [eq]: cmp/trait.Eq.html
545 /// [ord]: cmp/trait.Ord.html
546 /// [hash]: hash/trait.Hash.html
547 /// [asref]: convert/trait.AsRef.html
548 /// [asmut]: convert/trait.AsMut.html
549 /// [borrow]: borrow/trait.Borrow.html
550 /// [borrowmut]: borrow/trait.BorrowMut.html
551 /// [default]: default/trait.Default.html
552 /// [replace]: mem/fn.replace.html
553 /// [`IntoIterator`]: iter/trait.IntoIterator.html
555 #[stable(feature = "rust1", since = "1.0.0")]
558 #[doc(primitive = "slice")]
562 /// A dynamically-sized view into a contiguous sequence, `[T]`. Contiguous here
563 /// means that elements are laid out so that every element is the same
564 /// distance from its neighbors.
566 /// *[See also the `std::slice` module](slice/index.html).*
568 /// Slices are a view into a block of memory represented as a pointer and a
573 /// let vec = vec![1, 2, 3];
574 /// let int_slice = &vec[..];
575 /// // coercing an array to a slice
576 /// let str_slice: &[&str] = &["one", "two", "three"];
579 /// Slices are either mutable or shared. The shared slice type is `&[T]`,
580 /// while the mutable slice type is `&mut [T]`, where `T` represents the element
581 /// type. For example, you can mutate the block of memory that a mutable slice
585 /// let mut x = [1, 2, 3];
586 /// let x = &mut x[..]; // Take a full slice of `x`.
588 /// assert_eq!(x, &[1, 7, 3]);
591 /// As slices store the length of the sequence they refer to, they have twice
592 /// the size of pointers to [`Sized`](marker/trait.Sized.html) types.
593 /// Also see the reference on
594 /// [dynamically sized types](../reference/dynamically-sized-types.html).
597 /// # use std::rc::Rc;
598 /// let pointer_size = std::mem::size_of::<&u8>();
599 /// assert_eq!(2 * pointer_size, std::mem::size_of::<&[u8]>());
600 /// assert_eq!(2 * pointer_size, std::mem::size_of::<*const [u8]>());
601 /// assert_eq!(2 * pointer_size, std::mem::size_of::<Box<[u8]>>());
602 /// assert_eq!(2 * pointer_size, std::mem::size_of::<Rc<[u8]>>());
604 #[stable(feature = "rust1", since = "1.0.0")]
607 #[doc(primitive = "str")]
611 /// *[See also the `std::str` module](str/index.html).*
613 /// The `str` type, also called a 'string slice', is the most primitive string
614 /// type. It is usually seen in its borrowed form, `&str`. It is also the type
615 /// of string literals, `&'static str`.
617 /// String slices are always valid UTF-8.
621 /// String literals are string slices:
624 /// let hello = "Hello, world!";
626 /// // with an explicit type annotation
627 /// let hello: &'static str = "Hello, world!";
630 /// They are `'static` because they're stored directly in the final binary, and
631 /// so will be valid for the `'static` duration.
635 /// A `&str` is made up of two components: a pointer to some bytes, and a
636 /// length. You can look at these with the [`as_ptr`] and [`len`] methods:
642 /// let story = "Once upon a time...";
644 /// let ptr = story.as_ptr();
645 /// let len = story.len();
647 /// // story has nineteen bytes
648 /// assert_eq!(19, len);
650 /// // We can re-build a str out of ptr and len. This is all unsafe because
651 /// // we are responsible for making sure the two components are valid:
653 /// // First, we build a &[u8]...
654 /// let slice = slice::from_raw_parts(ptr, len);
656 /// // ... and then convert that slice into a string slice
657 /// str::from_utf8(slice)
660 /// assert_eq!(s, Ok(story));
663 /// [`as_ptr`]: #method.as_ptr
664 /// [`len`]: #method.len
666 /// Note: This example shows the internals of `&str`. `unsafe` should not be
667 /// used to get a string slice under normal circumstances. Use `as_str`
669 #[stable(feature = "rust1", since = "1.0.0")]
672 #[doc(primitive = "tuple")]
677 /// A finite heterogeneous sequence, `(T, U, ..)`.
679 /// Let's cover each of those in turn:
681 /// Tuples are *finite*. In other words, a tuple has a length. Here's a tuple
685 /// ("hello", 5, 'c');
688 /// 'Length' is also sometimes called 'arity' here; each tuple of a different
689 /// length is a different, distinct type.
691 /// Tuples are *heterogeneous*. This means that each element of the tuple can
692 /// have a different type. In that tuple above, it has the type:
696 /// (&'static str, i32, char)
697 /// # = ("hello", 5, 'c');
700 /// Tuples are a *sequence*. This means that they can be accessed by position;
701 /// this is called 'tuple indexing', and it looks like this:
704 /// let tuple = ("hello", 5, 'c');
706 /// assert_eq!(tuple.0, "hello");
707 /// assert_eq!(tuple.1, 5);
708 /// assert_eq!(tuple.2, 'c');
711 /// The sequential nature of the tuple applies to its implementations of various
712 /// traits. For example, in `PartialOrd` and `Ord`, the elements are compared
713 /// sequentially until the first non-equal set is found.
715 /// For more about tuples, see [the book](../book/ch03-02-data-types.html#the-tuple-type).
717 /// # Trait implementations
719 /// If every type inside a tuple implements one of the following traits, then a
720 /// tuple itself also implements it.
732 /// [`Clone`]: clone/trait.Clone.html
733 /// [`Copy`]: marker/trait.Copy.html
734 /// [`PartialEq`]: cmp/trait.PartialEq.html
735 /// [`Eq`]: cmp/trait.Eq.html
736 /// [`PartialOrd`]: cmp/trait.PartialOrd.html
737 /// [`Ord`]: cmp/trait.Ord.html
738 /// [`Debug`]: fmt/trait.Debug.html
739 /// [`Default`]: default/trait.Default.html
740 /// [`Hash`]: hash/trait.Hash.html
742 /// Due to a temporary restriction in Rust's type system, these traits are only
743 /// implemented on tuples of arity 12 or less. In the future, this may change.
750 /// let tuple = ("hello", 5, 'c');
752 /// assert_eq!(tuple.0, "hello");
755 /// Tuples are often used as a return type when you want to return more than
759 /// fn calculate_point() -> (i32, i32) {
760 /// // Don't do a calculation, that's not the point of the example
764 /// let point = calculate_point();
766 /// assert_eq!(point.0, 4);
767 /// assert_eq!(point.1, 5);
769 /// // Combining this with patterns can be nicer.
771 /// let (x, y) = calculate_point();
773 /// assert_eq!(x, 4);
774 /// assert_eq!(y, 5);
777 #[stable(feature = "rust1", since = "1.0.0")]
780 #[doc(primitive = "f32")]
781 /// A 32-bit floating point type (specifically, the "binary32" type defined in IEEE 754-2008).
783 /// This type can represent a wide range of decimal numbers, like `3.5`, `27`,
784 /// `-113.75`, `0.0078125`, `34359738368`, `0`, `-1`. So unlike integer types
785 /// (such as `i32`), floating point types can represent non-integer numbers,
788 /// However, being able to represent this wide range of numbers comes at the
789 /// cost of precision: floats can only represent some of the real numbers and
790 /// calculation with floats round to a nearby representable number. For example,
791 /// `5.0` and `1.0` can be exactly represented as `f32`, but `1.0 / 5.0` results
792 /// in `0.20000000298023223876953125` since `0.2` cannot be exactly represented
793 /// as `f32`. Note however, that printing floats with `println` and friends will
794 /// often discard insignificant digits: `println!("{}", 1.0f32 / 5.0f32)` will
797 /// Additionally, `f32` can represent a couple of special values:
799 /// - `-0`: this is just due to how floats are encoded. It is semantically
800 /// equivalent to `0` and `-0.0 == 0.0` results in `true`.
801 /// - [∞](#associatedconstant.INFINITY) and
802 /// [−∞](#associatedconstant.NEG_INFINITY): these result from calculations
803 /// like `1.0 / 0.0`.
804 /// - [NaN (not a number)](#associatedconstant.NAN): this value results from
805 /// calculations like `(-1.0).sqrt()`. NaN has some potentially unexpected
806 /// behavior: it is unequal to any float, including itself! It is also neither
807 /// smaller nor greater than any float, making it impossible to sort. Lastly,
808 /// it is considered infectious as almost all calculations where one of the
809 /// operands is NaN will also result in NaN.
811 /// For more information on floating point numbers, see [Wikipedia][wikipedia].
813 /// *[See also the `std::f32::consts` module](f32/consts/index.html).*
815 /// [wikipedia]: https://en.wikipedia.org/wiki/Single-precision_floating-point_format
816 #[stable(feature = "rust1", since = "1.0.0")]
819 #[doc(primitive = "f64")]
820 /// A 64-bit floating point type (specifically, the "binary64" type defined in IEEE 754-2008).
822 /// This type is very similar to [`f32`](primitive.f32.html), but has increased
823 /// precision by using twice as many bits. Please see [the documentation for
824 /// `f32`](primitive.f32.html) or [Wikipedia on double precision
825 /// values][wikipedia] for more information.
827 /// *[See also the `std::f64::consts` module](f64/consts/index.html).*
829 /// [wikipedia]: https://en.wikipedia.org/wiki/Double-precision_floating-point_format
830 #[stable(feature = "rust1", since = "1.0.0")]
833 #[doc(primitive = "i8")]
835 /// The 8-bit signed integer type.
836 #[stable(feature = "rust1", since = "1.0.0")]
839 #[doc(primitive = "i16")]
841 /// The 16-bit signed integer type.
842 #[stable(feature = "rust1", since = "1.0.0")]
845 #[doc(primitive = "i32")]
847 /// The 32-bit signed integer type.
848 #[stable(feature = "rust1", since = "1.0.0")]
851 #[doc(primitive = "i64")]
853 /// The 64-bit signed integer type.
854 #[stable(feature = "rust1", since = "1.0.0")]
857 #[doc(primitive = "i128")]
859 /// The 128-bit signed integer type.
860 #[stable(feature = "i128", since = "1.26.0")]
863 #[doc(primitive = "u8")]
865 /// The 8-bit unsigned integer type.
866 #[stable(feature = "rust1", since = "1.0.0")]
869 #[doc(primitive = "u16")]
871 /// The 16-bit unsigned integer type.
872 #[stable(feature = "rust1", since = "1.0.0")]
875 #[doc(primitive = "u32")]
877 /// The 32-bit unsigned integer type.
878 #[stable(feature = "rust1", since = "1.0.0")]
881 #[doc(primitive = "u64")]
883 /// The 64-bit unsigned integer type.
884 #[stable(feature = "rust1", since = "1.0.0")]
887 #[doc(primitive = "u128")]
889 /// The 128-bit unsigned integer type.
890 #[stable(feature = "i128", since = "1.26.0")]
893 #[doc(primitive = "isize")]
895 /// The pointer-sized signed integer type.
897 /// The size of this primitive is how many bytes it takes to reference any
898 /// location in memory. For example, on a 32 bit target, this is 4 bytes
899 /// and on a 64 bit target, this is 8 bytes.
900 #[stable(feature = "rust1", since = "1.0.0")]
903 #[doc(primitive = "usize")]
905 /// The pointer-sized unsigned integer type.
907 /// The size of this primitive is how many bytes it takes to reference any
908 /// location in memory. For example, on a 32 bit target, this is 4 bytes
909 /// and on a 64 bit target, this is 8 bytes.
910 #[stable(feature = "rust1", since = "1.0.0")]
913 #[doc(primitive = "reference")]
916 /// References, both shared and mutable.
918 /// A reference represents a borrow of some owned value. You can get one by using the `&` or `&mut`
919 /// operators on a value, or by using a `ref` or `ref mut` pattern.
921 /// For those familiar with pointers, a reference is just a pointer that is assumed to be
922 /// aligned, not null, and pointing to memory containing a valid value of `T` - for example,
923 /// `&bool` can only point to an allocation containing the integer values `1` (`true`) or `0`
924 /// (`false`), but creating a `&bool` that points to an allocation containing
925 /// the value `3` causes undefined behaviour.
926 /// In fact, `Option<&T>` has the same memory representation as a
927 /// nullable but aligned pointer, and can be passed across FFI boundaries as such.
929 /// In most cases, references can be used much like the original value. Field access, method
930 /// calling, and indexing work the same (save for mutability rules, of course). In addition, the
931 /// comparison operators transparently defer to the referent's implementation, allowing references
932 /// to be compared the same as owned values.
934 /// References have a lifetime attached to them, which represents the scope for which the borrow is
935 /// valid. A lifetime is said to "outlive" another one if its representative scope is as long or
936 /// longer than the other. The `'static` lifetime is the longest lifetime, which represents the
937 /// total life of the program. For example, string literals have a `'static` lifetime because the
938 /// text data is embedded into the binary of the program, rather than in an allocation that needs
939 /// to be dynamically managed.
941 /// `&mut T` references can be freely coerced into `&T` references with the same referent type, and
942 /// references with longer lifetimes can be freely coerced into references with shorter ones.
944 /// Reference equality by address, instead of comparing the values pointed to, is accomplished via
945 /// implicit reference-pointer coercion and raw pointer equality via [`ptr::eq`], while
946 /// [`PartialEq`] compares values.
948 /// [`ptr::eq`]: ptr/fn.eq.html
949 /// [`PartialEq`]: cmp/trait.PartialEq.html
955 /// let other_five = 5;
956 /// let five_ref = &five;
957 /// let same_five_ref = &five;
958 /// let other_five_ref = &other_five;
960 /// assert!(five_ref == same_five_ref);
961 /// assert!(five_ref == other_five_ref);
963 /// assert!(ptr::eq(five_ref, same_five_ref));
964 /// assert!(!ptr::eq(five_ref, other_five_ref));
967 /// For more information on how to use references, see [the book's section on "References and
968 /// Borrowing"][book-refs].
970 /// [book-refs]: ../book/ch04-02-references-and-borrowing.html
972 /// # Trait implementations
974 /// The following traits are implemented for all `&T`, regardless of the type of its referent:
977 /// * [`Clone`] \(Note that this will not defer to `T`'s `Clone` implementation if it exists!)
982 /// [`Copy`]: marker/trait.Copy.html
983 /// [`Clone`]: clone/trait.Clone.html
984 /// [`Deref`]: ops/trait.Deref.html
985 /// [`Borrow`]: borrow/trait.Borrow.html
986 /// [`Pointer`]: fmt/trait.Pointer.html
988 /// `&mut T` references get all of the above except `Copy` and `Clone` (to prevent creating
989 /// multiple simultaneous mutable borrows), plus the following, regardless of the type of its
995 /// [`DerefMut`]: ops/trait.DerefMut.html
996 /// [`BorrowMut`]: borrow/trait.BorrowMut.html
998 /// The following traits are implemented on `&T` references if the underlying `T` also implements
1001 /// * All the traits in [`std::fmt`] except [`Pointer`] and [`fmt::Write`]
1002 /// * [`PartialOrd`]
1007 /// * [`Fn`] \(in addition, `&T` references get [`FnMut`] and [`FnOnce`] if `T: Fn`)
1009 /// * [`ToSocketAddrs`]
1011 /// [`std::fmt`]: fmt/index.html
1012 /// [`fmt::Write`]: fmt/trait.Write.html
1013 /// [`PartialOrd`]: cmp/trait.PartialOrd.html
1014 /// [`Ord`]: cmp/trait.Ord.html
1015 /// [`PartialEq`]: cmp/trait.PartialEq.html
1016 /// [`Eq`]: cmp/trait.Eq.html
1017 /// [`AsRef`]: convert/trait.AsRef.html
1018 /// [`Fn`]: ops/trait.Fn.html
1019 /// [`FnMut`]: ops/trait.FnMut.html
1020 /// [`FnOnce`]: ops/trait.FnOnce.html
1021 /// [`Hash`]: hash/trait.Hash.html
1022 /// [`ToSocketAddrs`]: net/trait.ToSocketAddrs.html
1024 /// `&mut T` references get all of the above except `ToSocketAddrs`, plus the following, if `T`
1025 /// implements that trait:
1028 /// * [`FnMut`] \(in addition, `&mut T` references get [`FnOnce`] if `T: FnMut`)
1029 /// * [`fmt::Write`]
1031 /// * [`DoubleEndedIterator`]
1032 /// * [`ExactSizeIterator`]
1033 /// * [`FusedIterator`]
1034 /// * [`TrustedLen`]
1035 /// * [`Send`] \(note that `&T` references only get `Send` if `T: Sync`)
1041 /// [`AsMut`]: convert/trait.AsMut.html
1042 /// [`Iterator`]: iter/trait.Iterator.html
1043 /// [`DoubleEndedIterator`]: iter/trait.DoubleEndedIterator.html
1044 /// [`ExactSizeIterator`]: iter/trait.ExactSizeIterator.html
1045 /// [`FusedIterator`]: iter/trait.FusedIterator.html
1046 /// [`TrustedLen`]: iter/trait.TrustedLen.html
1047 /// [`Send`]: marker/trait.Send.html
1048 /// [`io::Write`]: io/trait.Write.html
1049 /// [`Read`]: io/trait.Read.html
1050 /// [`Seek`]: io/trait.Seek.html
1051 /// [`BufRead`]: io/trait.BufRead.html
1053 /// Note that due to method call deref coercion, simply calling a trait method will act like they
1054 /// work on references as well as they do on owned values! The implementations described here are
1055 /// meant for generic contexts, where the final type `T` is a type parameter or otherwise not
1057 #[stable(feature = "rust1", since = "1.0.0")]
1060 #[doc(primitive = "fn")]
1062 /// Function pointers, like `fn(usize) -> bool`.
1064 /// *See also the traits [`Fn`], [`FnMut`], and [`FnOnce`].*
1066 /// [`Fn`]: ops/trait.Fn.html
1067 /// [`FnMut`]: ops/trait.FnMut.html
1068 /// [`FnOnce`]: ops/trait.FnOnce.html
1070 /// Function pointers are pointers that point to *code*, not data. They can be called
1071 /// just like functions. Like references, function pointers are, among other things, assumed to
1072 /// not be null, so if you want to pass a function pointer over FFI and be able to accommodate null
1073 /// pointers, make your type `Option<fn()>` with your required signature.
1077 /// Plain function pointers are obtained by casting either plain functions, or closures that don't
1078 /// capture an environment:
1081 /// fn add_one(x: usize) -> usize {
1085 /// let ptr: fn(usize) -> usize = add_one;
1086 /// assert_eq!(ptr(5), 6);
1088 /// let clos: fn(usize) -> usize = |x| x + 5;
1089 /// assert_eq!(clos(5), 10);
1092 /// In addition to varying based on their signature, function pointers come in two flavors: safe
1093 /// and unsafe. Plain `fn()` function pointers can only point to safe functions,
1094 /// while `unsafe fn()` function pointers can point to safe or unsafe functions.
1097 /// fn add_one(x: usize) -> usize {
1101 /// unsafe fn add_one_unsafely(x: usize) -> usize {
1105 /// let safe_ptr: fn(usize) -> usize = add_one;
1107 /// //ERROR: mismatched types: expected normal fn, found unsafe fn
1108 /// //let bad_ptr: fn(usize) -> usize = add_one_unsafely;
1110 /// let unsafe_ptr: unsafe fn(usize) -> usize = add_one_unsafely;
1111 /// let really_safe_ptr: unsafe fn(usize) -> usize = add_one;
1116 /// On top of that, function pointers can vary based on what ABI they use. This
1117 /// is achieved by adding the `extern` keyword before the type, followed by the
1118 /// ABI in question. The default ABI is "Rust", i.e., `fn()` is the exact same
1119 /// type as `extern "Rust" fn()`. A pointer to a function with C ABI would have
1120 /// type `extern "C" fn()`.
1122 /// `extern "ABI" { ... }` blocks declare functions with ABI "ABI". The default
1123 /// here is "C", i.e., functions declared in an `extern {...}` block have "C"
1126 /// For more information and a list of supported ABIs, see [the nomicon's
1127 /// section on foreign calling conventions][nomicon-abi].
1129 /// ### Variadic functions
1131 /// Extern function declarations with the "C" or "cdecl" ABIs can also be *variadic*, allowing them
1132 /// to be called with a variable number of arguments. Normal Rust functions, even those with an
1133 /// `extern "ABI"`, cannot be variadic. For more information, see [the nomicon's section on
1134 /// variadic functions][nomicon-variadic].
1136 /// [nomicon-variadic]: ../nomicon/ffi.html#variadic-functions
1138 /// ### Creating function pointers
1140 /// When `bar` is the name of a function, then the expression `bar` is *not* a
1141 /// function pointer. Rather, it denotes a value of an unnameable type that
1142 /// uniquely identifies the function `bar`. The value is zero-sized because the
1143 /// type already identifies the function. This has the advantage that "calling"
1144 /// the value (it implements the `Fn*` traits) does not require dynamic
1147 /// This zero-sized type *coerces* to a regular function pointer. For example:
1152 /// fn bar(x: i32) {}
1154 /// let not_bar_ptr = bar; // `not_bar_ptr` is zero-sized, uniquely identifying `bar`
1155 /// assert_eq!(mem::size_of_val(¬_bar_ptr), 0);
1157 /// let bar_ptr: fn(i32) = not_bar_ptr; // force coercion to function pointer
1158 /// assert_eq!(mem::size_of_val(&bar_ptr), mem::size_of::<usize>());
1160 /// let footgun = &bar; // this is a shared reference to the zero-sized type identifying `bar`
1163 /// The last line shows that `&bar` is not a function pointer either. Rather, it
1164 /// is a reference to the function-specific ZST. `&bar` is basically never what you
1165 /// want when `bar` is a function.
1169 /// Function pointers implement the following traits:
1174 /// * [`PartialOrd`]
1180 /// [`Clone`]: clone/trait.Clone.html
1181 /// [`PartialEq`]: cmp/trait.PartialEq.html
1182 /// [`Eq`]: cmp/trait.Eq.html
1183 /// [`PartialOrd`]: cmp/trait.PartialOrd.html
1184 /// [`Ord`]: cmp/trait.Ord.html
1185 /// [`Hash`]: hash/trait.Hash.html
1186 /// [`Pointer`]: fmt/trait.Pointer.html
1187 /// [`Debug`]: fmt/trait.Debug.html
1189 /// Due to a temporary restriction in Rust's type system, these traits are only implemented on
1190 /// functions that take 12 arguments or less, with the `"Rust"` and `"C"` ABIs. In the future, this
1193 /// In addition, function pointers of *any* signature, ABI, or safety are [`Copy`], and all *safe*
1194 /// function pointers implement [`Fn`], [`FnMut`], and [`FnOnce`]. This works because these traits
1195 /// are specially known to the compiler.
1197 /// [`Copy`]: marker/trait.Copy.html
1198 #[stable(feature = "rust1", since = "1.0.0")]