]> git.lizzy.rs Git - rust.git/blob - library/std/src/primitive_docs.rs
Document char validity
[rust.git] / library / std / src / primitive_docs.rs
1 // `library/{std,core}/src/primitive_docs.rs` should have the same contents.
2 // These are different files so that relative links work properly without
3 // having to have `CARGO_PKG_NAME` set, but conceptually they should always be the same.
4 #[doc(primitive = "bool")]
5 #[doc(alias = "true")]
6 #[doc(alias = "false")]
7 /// The boolean type.
8 ///
9 /// The `bool` represents a value, which could only be either [`true`] or [`false`]. If you cast
10 /// a `bool` into an integer, [`true`] will be 1 and [`false`] will be 0.
11 ///
12 /// # Basic usage
13 ///
14 /// `bool` implements various traits, such as [`BitAnd`], [`BitOr`], [`Not`], etc.,
15 /// which allow us to perform boolean operations using `&`, `|` and `!`.
16 ///
17 /// [`if`] requires a `bool` value as its conditional. [`assert!`], which is an
18 /// important macro in testing, checks whether an expression is [`true`] and panics
19 /// if it isn't.
20 ///
21 /// ```
22 /// let bool_val = true & false | false;
23 /// assert!(!bool_val);
24 /// ```
25 ///
26 /// [`true`]: ../std/keyword.true.html
27 /// [`false`]: ../std/keyword.false.html
28 /// [`BitAnd`]: ops::BitAnd
29 /// [`BitOr`]: ops::BitOr
30 /// [`Not`]: ops::Not
31 /// [`if`]: ../std/keyword.if.html
32 ///
33 /// # Examples
34 ///
35 /// A trivial example of the usage of `bool`:
36 ///
37 /// ```
38 /// let praise_the_borrow_checker = true;
39 ///
40 /// // using the `if` conditional
41 /// if praise_the_borrow_checker {
42 ///     println!("oh, yeah!");
43 /// } else {
44 ///     println!("what?!!");
45 /// }
46 ///
47 /// // ... or, a match pattern
48 /// match praise_the_borrow_checker {
49 ///     true => println!("keep praising!"),
50 ///     false => println!("you should praise!"),
51 /// }
52 /// ```
53 ///
54 /// Also, since `bool` implements the [`Copy`] trait, we don't
55 /// have to worry about the move semantics (just like the integer and float primitives).
56 ///
57 /// Now an example of `bool` cast to integer type:
58 ///
59 /// ```
60 /// assert_eq!(true as i32, 1);
61 /// assert_eq!(false as i32, 0);
62 /// ```
63 #[stable(feature = "rust1", since = "1.0.0")]
64 mod prim_bool {}
65
66 #[doc(primitive = "never")]
67 #[doc(alias = "!")]
68 //
69 /// The `!` type, also called "never".
70 ///
71 /// `!` represents the type of computations which never resolve to any value at all. For example,
72 /// the [`exit`] function `fn exit(code: i32) -> !` exits the process without ever returning, and
73 /// so returns `!`.
74 ///
75 /// `break`, `continue` and `return` expressions also have type `!`. For example we are allowed to
76 /// write:
77 ///
78 /// ```
79 /// #![feature(never_type)]
80 /// # fn foo() -> u32 {
81 /// let x: ! = {
82 ///     return 123
83 /// };
84 /// # }
85 /// ```
86 ///
87 /// Although the `let` is pointless here, it illustrates the meaning of `!`. Since `x` is never
88 /// assigned a value (because `return` returns from the entire function), `x` can be given type
89 /// `!`. We could also replace `return 123` with a `panic!` or a never-ending `loop` and this code
90 /// would still be valid.
91 ///
92 /// A more realistic usage of `!` is in this code:
93 ///
94 /// ```
95 /// # fn get_a_number() -> Option<u32> { None }
96 /// # loop {
97 /// let num: u32 = match get_a_number() {
98 ///     Some(num) => num,
99 ///     None => break,
100 /// };
101 /// # }
102 /// ```
103 ///
104 /// Both match arms must produce values of type [`u32`], but since `break` never produces a value
105 /// at all we know it can never produce a value which isn't a [`u32`]. This illustrates another
106 /// behaviour of the `!` type - expressions with type `!` will coerce into any other type.
107 ///
108 /// [`u32`]: prim@u32
109 #[doc = concat!("[`exit`]: ", include_str!("../primitive_docs/process_exit.md"))]
110 ///
111 /// # `!` and generics
112 ///
113 /// ## Infallible errors
114 ///
115 /// The main place you'll see `!` used explicitly is in generic code. Consider the [`FromStr`]
116 /// trait:
117 ///
118 /// ```
119 /// trait FromStr: Sized {
120 ///     type Err;
121 ///     fn from_str(s: &str) -> Result<Self, Self::Err>;
122 /// }
123 /// ```
124 ///
125 /// When implementing this trait for [`String`] we need to pick a type for [`Err`]. And since
126 /// converting a string into a string will never result in an error, the appropriate type is `!`.
127 /// (Currently the type actually used is an enum with no variants, though this is only because `!`
128 /// was added to Rust at a later date and it may change in the future.) With an [`Err`] type of
129 /// `!`, if we have to call [`String::from_str`] for some reason the result will be a
130 /// [`Result<String, !>`] which we can unpack like this:
131 ///
132 /// ```
133 /// #![feature(exhaustive_patterns)]
134 /// use std::str::FromStr;
135 /// let Ok(s) = String::from_str("hello");
136 /// ```
137 ///
138 /// Since the [`Err`] variant contains a `!`, it can never occur. If the `exhaustive_patterns`
139 /// feature is present this means we can exhaustively match on [`Result<T, !>`] by just taking the
140 /// [`Ok`] variant. This illustrates another behaviour of `!` - it can be used to "delete" certain
141 /// enum variants from generic types like `Result`.
142 ///
143 /// ## Infinite loops
144 ///
145 /// While [`Result<T, !>`] is very useful for removing errors, `!` can also be used to remove
146 /// successes as well. If we think of [`Result<T, !>`] as "if this function returns, it has not
147 /// errored," we get a very intuitive idea of [`Result<!, E>`] as well: if the function returns, it
148 /// *has* errored.
149 ///
150 /// For example, consider the case of a simple web server, which can be simplified to:
151 ///
152 /// ```ignore (hypothetical-example)
153 /// loop {
154 ///     let (client, request) = get_request().expect("disconnected");
155 ///     let response = request.process();
156 ///     response.send(client);
157 /// }
158 /// ```
159 ///
160 /// Currently, this isn't ideal, because we simply panic whenever we fail to get a new connection.
161 /// Instead, we'd like to keep track of this error, like this:
162 ///
163 /// ```ignore (hypothetical-example)
164 /// loop {
165 ///     match get_request() {
166 ///         Err(err) => break err,
167 ///         Ok((client, request)) => {
168 ///             let response = request.process();
169 ///             response.send(client);
170 ///         },
171 ///     }
172 /// }
173 /// ```
174 ///
175 /// Now, when the server disconnects, we exit the loop with an error instead of panicking. While it
176 /// might be intuitive to simply return the error, we might want to wrap it in a [`Result<!, E>`]
177 /// instead:
178 ///
179 /// ```ignore (hypothetical-example)
180 /// fn server_loop() -> Result<!, ConnectionError> {
181 ///     loop {
182 ///         let (client, request) = get_request()?;
183 ///         let response = request.process();
184 ///         response.send(client);
185 ///     }
186 /// }
187 /// ```
188 ///
189 /// Now, we can use `?` instead of `match`, and the return type makes a lot more sense: if the loop
190 /// ever stops, it means that an error occurred. We don't even have to wrap the loop in an `Ok`
191 /// because `!` coerces to `Result<!, ConnectionError>` automatically.
192 ///
193 /// [`String::from_str`]: str::FromStr::from_str
194 #[doc = concat!("[`String`]: ", include_str!("../primitive_docs/string_string.md"))]
195 /// [`FromStr`]: str::FromStr
196 ///
197 /// # `!` and traits
198 ///
199 /// When writing your own traits, `!` should have an `impl` whenever there is an obvious `impl`
200 /// which doesn't `panic!`. The reason is that functions returning an `impl Trait` where `!`
201 /// does not have an `impl` of `Trait` cannot diverge as their only possible code path. In other
202 /// words, they can't return `!` from every code path. As an example, this code doesn't compile:
203 ///
204 /// ```compile_fail
205 /// use std::ops::Add;
206 ///
207 /// fn foo() -> impl Add<u32> {
208 ///     unimplemented!()
209 /// }
210 /// ```
211 ///
212 /// But this code does:
213 ///
214 /// ```
215 /// use std::ops::Add;
216 ///
217 /// fn foo() -> impl Add<u32> {
218 ///     if true {
219 ///         unimplemented!()
220 ///     } else {
221 ///         0
222 ///     }
223 /// }
224 /// ```
225 ///
226 /// The reason is that, in the first example, there are many possible types that `!` could coerce
227 /// to, because many types implement `Add<u32>`. However, in the second example,
228 /// the `else` branch returns a `0`, which the compiler infers from the return type to be of type
229 /// `u32`. Since `u32` is a concrete type, `!` can and will be coerced to it. See issue [#36375]
230 /// for more information on this quirk of `!`.
231 ///
232 /// [#36375]: https://github.com/rust-lang/rust/issues/36375
233 ///
234 /// As it turns out, though, most traits can have an `impl` for `!`. Take [`Debug`]
235 /// for example:
236 ///
237 /// ```
238 /// #![feature(never_type)]
239 /// # use std::fmt;
240 /// # trait Debug {
241 /// #     fn fmt(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result;
242 /// # }
243 /// impl Debug for ! {
244 ///     fn fmt(&self, formatter: &mut fmt::Formatter<'_>) -> fmt::Result {
245 ///         *self
246 ///     }
247 /// }
248 /// ```
249 ///
250 /// Once again we're using `!`'s ability to coerce into any other type, in this case
251 /// [`fmt::Result`]. Since this method takes a `&!` as an argument we know that it can never be
252 /// called (because there is no value of type `!` for it to be called with). Writing `*self`
253 /// essentially tells the compiler "We know that this code can never be run, so just treat the
254 /// entire function body as having type [`fmt::Result`]". This pattern can be used a lot when
255 /// implementing traits for `!`. Generally, any trait which only has methods which take a `self`
256 /// parameter should have such an impl.
257 ///
258 /// On the other hand, one trait which would not be appropriate to implement is [`Default`]:
259 ///
260 /// ```
261 /// trait Default {
262 ///     fn default() -> Self;
263 /// }
264 /// ```
265 ///
266 /// Since `!` has no values, it has no default value either. It's true that we could write an
267 /// `impl` for this which simply panics, but the same is true for any type (we could `impl
268 /// Default` for (eg.) [`File`] by just making [`default()`] panic.)
269 ///
270 #[doc = concat!("[`File`]: ", include_str!("../primitive_docs/fs_file.md"))]
271 /// [`Debug`]: fmt::Debug
272 /// [`default()`]: Default::default
273 ///
274 #[unstable(feature = "never_type", issue = "35121")]
275 mod prim_never {}
276
277 #[doc(primitive = "char")]
278 /// A character type.
279 ///
280 /// The `char` type represents a single character. More specifically, since
281 /// 'character' isn't a well-defined concept in Unicode, `char` is a '[Unicode
282 /// scalar value]'.
283 ///
284 /// This documentation describes a number of methods and trait implementations on the
285 /// `char` type. For technical reasons, there is additional, separate
286 /// documentation in [the `std::char` module](char/index.html) as well.
287 ///
288 /// # Validity
289 ///
290 /// A `char` is a '[Unicode scalar value]', which is any '[Unicode code point]'
291 /// other than a [surrogate code point]. This has a fixed numerical definition:
292 /// code points are in the range `'\0'` to `char::MAX` (`'\u{10FFFF}'`), inclusive.
293 /// Surrogate code points, used by UTF-16, are in the range U+D800 to U+DFFF.
294 ///
295 /// No `char` may be constructed, whether as a literal or at runtime, that is not a
296 /// Unicode scalar value:
297 ///
298 /// ```text
299 /// let forbidden_chars = [
300 ///     // Each of these is a compiler error
301 ///     '\u{D800}', '\u{DFFF}', '\u{110000}',
302 ///
303 ///     // Panics; from_u32 returns None.
304 ///     char::from_u32(0xDE01).unwrap(),
305 ///
306 ///     // Undefined behaviour
307 ///     unsafe { char::from_u32_unchecked(0x110000) },
308 /// ];
309 /// ```
310 ///
311 /// Unicode is regularly updated. Many USVs are not currently assigned to a
312 /// character, but may be in the future ("reserved"); some will never be a character
313 /// ("noncharacters"); and some may be given different meanings by different users
314 /// ("private use").
315 ///
316 /// [Unicode scalar value]: https://www.unicode.org/glossary/#unicode_scalar_value
317 /// [Unicode code point]: https://www.unicode.org/glossary/#code_point
318 /// [surrogate code point]: https://www.unicode.org/glossary/#surrogate_code_point
319 ///
320 /// # Representation
321 ///
322 /// `char` is always four bytes in size. This is a different representation than
323 /// a given character would have as part of a [`String`]. For example:
324 ///
325 /// ```
326 /// let v = vec!['h', 'e', 'l', 'l', 'o'];
327 ///
328 /// // five elements times four bytes for each element
329 /// assert_eq!(20, v.len() * std::mem::size_of::<char>());
330 ///
331 /// let s = String::from("hello");
332 ///
333 /// // five elements times one byte per element
334 /// assert_eq!(5, s.len() * std::mem::size_of::<u8>());
335 /// ```
336 ///
337 #[doc = concat!("[`String`]: ", include_str!("../primitive_docs/string_string.md"))]
338 ///
339 /// As always, remember that a human intuition for 'character' might not map to
340 /// Unicode's definitions. For example, despite looking similar, the 'é'
341 /// character is one Unicode code point while 'é' is two Unicode code points:
342 ///
343 /// ```
344 /// let mut chars = "é".chars();
345 /// // U+00e9: 'latin small letter e with acute'
346 /// assert_eq!(Some('\u{00e9}'), chars.next());
347 /// assert_eq!(None, chars.next());
348 ///
349 /// let mut chars = "é".chars();
350 /// // U+0065: 'latin small letter e'
351 /// assert_eq!(Some('\u{0065}'), chars.next());
352 /// // U+0301: 'combining acute accent'
353 /// assert_eq!(Some('\u{0301}'), chars.next());
354 /// assert_eq!(None, chars.next());
355 /// ```
356 ///
357 /// This means that the contents of the first string above _will_ fit into a
358 /// `char` while the contents of the second string _will not_. Trying to create
359 /// a `char` literal with the contents of the second string gives an error:
360 ///
361 /// ```text
362 /// error: character literal may only contain one codepoint: 'é'
363 /// let c = 'é';
364 ///         ^^^
365 /// ```
366 ///
367 /// Another implication of the 4-byte fixed size of a `char` is that
368 /// per-`char` processing can end up using a lot more memory:
369 ///
370 /// ```
371 /// let s = String::from("love: ❤️");
372 /// let v: Vec<char> = s.chars().collect();
373 ///
374 /// assert_eq!(12, std::mem::size_of_val(&s[..]));
375 /// assert_eq!(32, std::mem::size_of_val(&v[..]));
376 /// ```
377 #[stable(feature = "rust1", since = "1.0.0")]
378 mod prim_char {}
379
380 #[doc(primitive = "unit")]
381 #[doc(alias = "(")]
382 #[doc(alias = ")")]
383 #[doc(alias = "()")]
384 //
385 /// The `()` type, also called "unit".
386 ///
387 /// The `()` type has exactly one value `()`, and is used when there
388 /// is no other meaningful value that could be returned. `()` is most
389 /// commonly seen implicitly: functions without a `-> ...` implicitly
390 /// have return type `()`, that is, these are equivalent:
391 ///
392 /// ```rust
393 /// fn long() -> () {}
394 ///
395 /// fn short() {}
396 /// ```
397 ///
398 /// The semicolon `;` can be used to discard the result of an
399 /// expression at the end of a block, making the expression (and thus
400 /// the block) evaluate to `()`. For example,
401 ///
402 /// ```rust
403 /// fn returns_i64() -> i64 {
404 ///     1i64
405 /// }
406 /// fn returns_unit() {
407 ///     1i64;
408 /// }
409 ///
410 /// let is_i64 = {
411 ///     returns_i64()
412 /// };
413 /// let is_unit = {
414 ///     returns_i64();
415 /// };
416 /// ```
417 ///
418 #[stable(feature = "rust1", since = "1.0.0")]
419 mod prim_unit {}
420
421 #[doc(primitive = "pointer")]
422 #[doc(alias = "ptr")]
423 #[doc(alias = "*")]
424 #[doc(alias = "*const")]
425 #[doc(alias = "*mut")]
426 //
427 /// Raw, unsafe pointers, `*const T`, and `*mut T`.
428 ///
429 /// *[See also the `std::ptr` module](ptr).*
430 ///
431 /// Working with raw pointers in Rust is uncommon, typically limited to a few patterns.
432 /// Raw pointers can be unaligned or [`null`]. However, when a raw pointer is
433 /// dereferenced (using the `*` operator), it must be non-null and aligned.
434 ///
435 /// Storing through a raw pointer using `*ptr = data` calls `drop` on the old value, so
436 /// [`write`] must be used if the type has drop glue and memory is not already
437 /// initialized - otherwise `drop` would be called on the uninitialized memory.
438 ///
439 /// Use the [`null`] and [`null_mut`] functions to create null pointers, and the
440 /// [`is_null`] method of the `*const T` and `*mut T` types to check for null.
441 /// The `*const T` and `*mut T` types also define the [`offset`] method, for
442 /// pointer math.
443 ///
444 /// # Common ways to create raw pointers
445 ///
446 /// ## 1. Coerce a reference (`&T`) or mutable reference (`&mut T`).
447 ///
448 /// ```
449 /// let my_num: i32 = 10;
450 /// let my_num_ptr: *const i32 = &my_num;
451 /// let mut my_speed: i32 = 88;
452 /// let my_speed_ptr: *mut i32 = &mut my_speed;
453 /// ```
454 ///
455 /// To get a pointer to a boxed value, dereference the box:
456 ///
457 /// ```
458 /// let my_num: Box<i32> = Box::new(10);
459 /// let my_num_ptr: *const i32 = &*my_num;
460 /// let mut my_speed: Box<i32> = Box::new(88);
461 /// let my_speed_ptr: *mut i32 = &mut *my_speed;
462 /// ```
463 ///
464 /// This does not take ownership of the original allocation
465 /// and requires no resource management later,
466 /// but you must not use the pointer after its lifetime.
467 ///
468 /// ## 2. Consume a box (`Box<T>`).
469 ///
470 /// The [`into_raw`] function consumes a box and returns
471 /// the raw pointer. It doesn't destroy `T` or deallocate any memory.
472 ///
473 /// ```
474 /// let my_speed: Box<i32> = Box::new(88);
475 /// let my_speed: *mut i32 = Box::into_raw(my_speed);
476 ///
477 /// // By taking ownership of the original `Box<T>` though
478 /// // we are obligated to put it together later to be destroyed.
479 /// unsafe {
480 ///     drop(Box::from_raw(my_speed));
481 /// }
482 /// ```
483 ///
484 /// Note that here the call to [`drop`] is for clarity - it indicates
485 /// that we are done with the given value and it should be destroyed.
486 ///
487 /// ## 3. Create it using `ptr::addr_of!`
488 ///
489 /// Instead of coercing a reference to a raw pointer, you can use the macros
490 /// [`ptr::addr_of!`] (for `*const T`) and [`ptr::addr_of_mut!`] (for `*mut T`).
491 /// These macros allow you to create raw pointers to fields to which you cannot
492 /// create a reference (without causing undefined behaviour), such as an
493 /// unaligned field. This might be necessary if packed structs or uninitialized
494 /// memory is involved.
495 ///
496 /// ```
497 /// #[derive(Debug, Default, Copy, Clone)]
498 /// #[repr(C, packed)]
499 /// struct S {
500 ///     aligned: u8,
501 ///     unaligned: u32,
502 /// }
503 /// let s = S::default();
504 /// let p = std::ptr::addr_of!(s.unaligned); // not allowed with coercion
505 /// ```
506 ///
507 /// ## 4. Get it from C.
508 ///
509 /// ```
510 /// # #![feature(rustc_private)]
511 /// extern crate libc;
512 ///
513 /// use std::mem;
514 ///
515 /// unsafe {
516 ///     let my_num: *mut i32 = libc::malloc(mem::size_of::<i32>()) as *mut i32;
517 ///     if my_num.is_null() {
518 ///         panic!("failed to allocate memory");
519 ///     }
520 ///     libc::free(my_num as *mut libc::c_void);
521 /// }
522 /// ```
523 ///
524 /// Usually you wouldn't literally use `malloc` and `free` from Rust,
525 /// but C APIs hand out a lot of pointers generally, so are a common source
526 /// of raw pointers in Rust.
527 ///
528 /// [`null`]: ptr::null
529 /// [`null_mut`]: ptr::null_mut
530 /// [`is_null`]: pointer::is_null
531 /// [`offset`]: pointer::offset
532 #[doc = concat!("[`into_raw`]: ", include_str!("../primitive_docs/box_into_raw.md"))]
533 /// [`drop`]: mem::drop
534 /// [`write`]: ptr::write
535 #[stable(feature = "rust1", since = "1.0.0")]
536 mod prim_pointer {}
537
538 #[doc(primitive = "array")]
539 #[doc(alias = "[]")]
540 #[doc(alias = "[T;N]")] // unfortunately, rustdoc doesn't have fuzzy search for aliases
541 #[doc(alias = "[T; N]")]
542 /// A fixed-size array, denoted `[T; N]`, for the element type, `T`, and the
543 /// non-negative compile-time constant size, `N`.
544 ///
545 /// There are two syntactic forms for creating an array:
546 ///
547 /// * A list with each element, i.e., `[x, y, z]`.
548 /// * A repeat expression `[x; N]`, which produces an array with `N` copies of `x`.
549 ///   The type of `x` must be [`Copy`].
550 ///
551 /// Note that `[expr; 0]` is allowed, and produces an empty array.
552 /// This will still evaluate `expr`, however, and immediately drop the resulting value, so
553 /// be mindful of side effects.
554 ///
555 /// Arrays of *any* size implement the following traits if the element type allows it:
556 ///
557 /// - [`Copy`]
558 /// - [`Clone`]
559 /// - [`Debug`]
560 /// - [`IntoIterator`] (implemented for `[T; N]`, `&[T; N]` and `&mut [T; N]`)
561 /// - [`PartialEq`], [`PartialOrd`], [`Eq`], [`Ord`]
562 /// - [`Hash`]
563 /// - [`AsRef`], [`AsMut`]
564 /// - [`Borrow`], [`BorrowMut`]
565 ///
566 /// Arrays of sizes from 0 to 32 (inclusive) implement the [`Default`] trait
567 /// if the element type allows it. As a stopgap, trait implementations are
568 /// statically generated up to size 32.
569 ///
570 /// Arrays coerce to [slices (`[T]`)][slice], so a slice method may be called on
571 /// an array. Indeed, this provides most of the API for working with arrays.
572 /// Slices have a dynamic size and do not coerce to arrays.
573 ///
574 /// You can move elements out of an array with a [slice pattern]. If you want
575 /// one element, see [`mem::replace`].
576 ///
577 /// # Examples
578 ///
579 /// ```
580 /// let mut array: [i32; 3] = [0; 3];
581 ///
582 /// array[1] = 1;
583 /// array[2] = 2;
584 ///
585 /// assert_eq!([1, 2], &array[1..]);
586 ///
587 /// // This loop prints: 0 1 2
588 /// for x in array {
589 ///     print!("{} ", x);
590 /// }
591 /// ```
592 ///
593 /// You can also iterate over reference to the array's elements:
594 ///
595 /// ```
596 /// let array: [i32; 3] = [0; 3];
597 ///
598 /// for x in &array { }
599 /// ```
600 ///
601 /// You can use a [slice pattern] to move elements out of an array:
602 ///
603 /// ```
604 /// fn move_away(_: String) { /* Do interesting things. */ }
605 ///
606 /// let [john, roa] = ["John".to_string(), "Roa".to_string()];
607 /// move_away(john);
608 /// move_away(roa);
609 /// ```
610 ///
611 /// # Editions
612 ///
613 /// Prior to Rust 1.53, arrays did not implement [`IntoIterator`] by value, so the method call
614 /// `array.into_iter()` auto-referenced into a [slice iterator](slice::iter). Right now, the old
615 /// behavior is preserved in the 2015 and 2018 editions of Rust for compatibility, ignoring
616 /// [`IntoIterator`] by value. In the future, the behavior on the 2015 and 2018 edition
617 /// might be made consistent to the behavior of later editions.
618 ///
619 /// ```rust,edition2018
620 /// // Rust 2015 and 2018:
621 ///
622 /// # #![allow(array_into_iter)] // override our `deny(warnings)`
623 /// let array: [i32; 3] = [0; 3];
624 ///
625 /// // This creates a slice iterator, producing references to each value.
626 /// for item in array.into_iter().enumerate() {
627 ///     let (i, x): (usize, &i32) = item;
628 ///     println!("array[{}] = {}", i, x);
629 /// }
630 ///
631 /// // The `array_into_iter` lint suggests this change for future compatibility:
632 /// for item in array.iter().enumerate() {
633 ///     let (i, x): (usize, &i32) = item;
634 ///     println!("array[{}] = {}", i, x);
635 /// }
636 ///
637 /// // You can explicitly iterate an array by value using `IntoIterator::into_iter`
638 /// for item in IntoIterator::into_iter(array).enumerate() {
639 ///     let (i, x): (usize, i32) = item;
640 ///     println!("array[{}] = {}", i, x);
641 /// }
642 /// ```
643 ///
644 /// Starting in the 2021 edition, `array.into_iter()` uses `IntoIterator` normally to iterate
645 /// by value, and `iter()` should be used to iterate by reference like previous editions.
646 ///
647 /// ```rust,edition2021
648 /// // Rust 2021:
649 ///
650 /// let array: [i32; 3] = [0; 3];
651 ///
652 /// // This iterates by reference:
653 /// for item in array.iter().enumerate() {
654 ///     let (i, x): (usize, &i32) = item;
655 ///     println!("array[{}] = {}", i, x);
656 /// }
657 ///
658 /// // This iterates by value:
659 /// for item in array.into_iter().enumerate() {
660 ///     let (i, x): (usize, i32) = item;
661 ///     println!("array[{}] = {}", i, x);
662 /// }
663 /// ```
664 ///
665 /// Future language versions might start treating the `array.into_iter()`
666 /// syntax on editions 2015 and 2018 the same as on edition 2021. So code using
667 /// those older editions should still be written with this change in mind, to
668 /// prevent breakage in the future. The safest way to accomplish this is to
669 /// avoid the `into_iter` syntax on those editions. If an edition update is not
670 /// viable/desired, there are multiple alternatives:
671 /// * use `iter`, equivalent to the old behavior, creating references
672 /// * use [`IntoIterator::into_iter`], equivalent to the post-2021 behavior (Rust 1.53+)
673 /// * replace `for ... in array.into_iter() {` with `for ... in array {`,
674 ///   equivalent to the post-2021 behavior (Rust 1.53+)
675 ///
676 /// ```rust,edition2018
677 /// // Rust 2015 and 2018:
678 ///
679 /// let array: [i32; 3] = [0; 3];
680 ///
681 /// // This iterates by reference:
682 /// for item in array.iter() {
683 ///     let x: &i32 = item;
684 ///     println!("{}", x);
685 /// }
686 ///
687 /// // This iterates by value:
688 /// for item in IntoIterator::into_iter(array) {
689 ///     let x: i32 = item;
690 ///     println!("{}", x);
691 /// }
692 ///
693 /// // This iterates by value:
694 /// for item in array {
695 ///     let x: i32 = item;
696 ///     println!("{}", x);
697 /// }
698 ///
699 /// // IntoIter can also start a chain.
700 /// // This iterates by value:
701 /// for item in IntoIterator::into_iter(array).enumerate() {
702 ///     let (i, x): (usize, i32) = item;
703 ///     println!("array[{}] = {}", i, x);
704 /// }
705 /// ```
706 ///
707 /// [slice]: prim@slice
708 /// [`Debug`]: fmt::Debug
709 /// [`Hash`]: hash::Hash
710 /// [`Borrow`]: borrow::Borrow
711 /// [`BorrowMut`]: borrow::BorrowMut
712 /// [slice pattern]: ../reference/patterns.html#slice-patterns
713 #[stable(feature = "rust1", since = "1.0.0")]
714 mod prim_array {}
715
716 #[doc(primitive = "slice")]
717 #[doc(alias = "[")]
718 #[doc(alias = "]")]
719 #[doc(alias = "[]")]
720 /// A dynamically-sized view into a contiguous sequence, `[T]`. Contiguous here
721 /// means that elements are laid out so that every element is the same
722 /// distance from its neighbors.
723 ///
724 /// *[See also the `std::slice` module](crate::slice).*
725 ///
726 /// Slices are a view into a block of memory represented as a pointer and a
727 /// length.
728 ///
729 /// ```
730 /// // slicing a Vec
731 /// let vec = vec![1, 2, 3];
732 /// let int_slice = &vec[..];
733 /// // coercing an array to a slice
734 /// let str_slice: &[&str] = &["one", "two", "three"];
735 /// ```
736 ///
737 /// Slices are either mutable or shared. The shared slice type is `&[T]`,
738 /// while the mutable slice type is `&mut [T]`, where `T` represents the element
739 /// type. For example, you can mutate the block of memory that a mutable slice
740 /// points to:
741 ///
742 /// ```
743 /// let mut x = [1, 2, 3];
744 /// let x = &mut x[..]; // Take a full slice of `x`.
745 /// x[1] = 7;
746 /// assert_eq!(x, &[1, 7, 3]);
747 /// ```
748 ///
749 /// As slices store the length of the sequence they refer to, they have twice
750 /// the size of pointers to [`Sized`](marker/trait.Sized.html) types.
751 /// Also see the reference on
752 /// [dynamically sized types](../reference/dynamically-sized-types.html).
753 ///
754 /// ```
755 /// # use std::rc::Rc;
756 /// let pointer_size = std::mem::size_of::<&u8>();
757 /// assert_eq!(2 * pointer_size, std::mem::size_of::<&[u8]>());
758 /// assert_eq!(2 * pointer_size, std::mem::size_of::<*const [u8]>());
759 /// assert_eq!(2 * pointer_size, std::mem::size_of::<Box<[u8]>>());
760 /// assert_eq!(2 * pointer_size, std::mem::size_of::<Rc<[u8]>>());
761 /// ```
762 #[stable(feature = "rust1", since = "1.0.0")]
763 mod prim_slice {}
764
765 #[doc(primitive = "str")]
766 //
767 /// String slices.
768 ///
769 /// *[See also the `std::str` module](crate::str).*
770 ///
771 /// The `str` type, also called a 'string slice', is the most primitive string
772 /// type. It is usually seen in its borrowed form, `&str`. It is also the type
773 /// of string literals, `&'static str`.
774 ///
775 /// String slices are always valid UTF-8.
776 ///
777 /// # Examples
778 ///
779 /// String literals are string slices:
780 ///
781 /// ```
782 /// let hello = "Hello, world!";
783 ///
784 /// // with an explicit type annotation
785 /// let hello: &'static str = "Hello, world!";
786 /// ```
787 ///
788 /// They are `'static` because they're stored directly in the final binary, and
789 /// so will be valid for the `'static` duration.
790 ///
791 /// # Representation
792 ///
793 /// A `&str` is made up of two components: a pointer to some bytes, and a
794 /// length. You can look at these with the [`as_ptr`] and [`len`] methods:
795 ///
796 /// ```
797 /// use std::slice;
798 /// use std::str;
799 ///
800 /// let story = "Once upon a time...";
801 ///
802 /// let ptr = story.as_ptr();
803 /// let len = story.len();
804 ///
805 /// // story has nineteen bytes
806 /// assert_eq!(19, len);
807 ///
808 /// // We can re-build a str out of ptr and len. This is all unsafe because
809 /// // we are responsible for making sure the two components are valid:
810 /// let s = unsafe {
811 ///     // First, we build a &[u8]...
812 ///     let slice = slice::from_raw_parts(ptr, len);
813 ///
814 ///     // ... and then convert that slice into a string slice
815 ///     str::from_utf8(slice)
816 /// };
817 ///
818 /// assert_eq!(s, Ok(story));
819 /// ```
820 ///
821 /// [`as_ptr`]: str::as_ptr
822 /// [`len`]: str::len
823 ///
824 /// Note: This example shows the internals of `&str`. `unsafe` should not be
825 /// used to get a string slice under normal circumstances. Use `as_str`
826 /// instead.
827 #[stable(feature = "rust1", since = "1.0.0")]
828 mod prim_str {}
829
830 #[doc(primitive = "tuple")]
831 #[doc(alias = "(")]
832 #[doc(alias = ")")]
833 #[doc(alias = "()")]
834 //
835 /// A finite heterogeneous sequence, `(T, U, ..)`.
836 ///
837 /// Let's cover each of those in turn:
838 ///
839 /// Tuples are *finite*. In other words, a tuple has a length. Here's a tuple
840 /// of length `3`:
841 ///
842 /// ```
843 /// ("hello", 5, 'c');
844 /// ```
845 ///
846 /// 'Length' is also sometimes called 'arity' here; each tuple of a different
847 /// length is a different, distinct type.
848 ///
849 /// Tuples are *heterogeneous*. This means that each element of the tuple can
850 /// have a different type. In that tuple above, it has the type:
851 ///
852 /// ```
853 /// # let _:
854 /// (&'static str, i32, char)
855 /// # = ("hello", 5, 'c');
856 /// ```
857 ///
858 /// Tuples are a *sequence*. This means that they can be accessed by position;
859 /// this is called 'tuple indexing', and it looks like this:
860 ///
861 /// ```rust
862 /// let tuple = ("hello", 5, 'c');
863 ///
864 /// assert_eq!(tuple.0, "hello");
865 /// assert_eq!(tuple.1, 5);
866 /// assert_eq!(tuple.2, 'c');
867 /// ```
868 ///
869 /// The sequential nature of the tuple applies to its implementations of various
870 /// traits. For example, in [`PartialOrd`] and [`Ord`], the elements are compared
871 /// sequentially until the first non-equal set is found.
872 ///
873 /// For more about tuples, see [the book](../book/ch03-02-data-types.html#the-tuple-type).
874 ///
875 /// # Trait implementations
876 ///
877 /// If every type inside a tuple implements one of the following traits, then a
878 /// tuple itself also implements it.
879 ///
880 /// * [`Clone`]
881 /// * [`Copy`]
882 /// * [`PartialEq`]
883 /// * [`Eq`]
884 /// * [`PartialOrd`]
885 /// * [`Ord`]
886 /// * [`Debug`]
887 /// * [`Default`]
888 /// * [`Hash`]
889 ///
890 /// [`Debug`]: fmt::Debug
891 /// [`Hash`]: hash::Hash
892 ///
893 /// Due to a temporary restriction in Rust's type system, these traits are only
894 /// implemented on tuples of arity 12 or less. In the future, this may change.
895 ///
896 /// # Examples
897 ///
898 /// Basic usage:
899 ///
900 /// ```
901 /// let tuple = ("hello", 5, 'c');
902 ///
903 /// assert_eq!(tuple.0, "hello");
904 /// ```
905 ///
906 /// Tuples are often used as a return type when you want to return more than
907 /// one value:
908 ///
909 /// ```
910 /// fn calculate_point() -> (i32, i32) {
911 ///     // Don't do a calculation, that's not the point of the example
912 ///     (4, 5)
913 /// }
914 ///
915 /// let point = calculate_point();
916 ///
917 /// assert_eq!(point.0, 4);
918 /// assert_eq!(point.1, 5);
919 ///
920 /// // Combining this with patterns can be nicer.
921 ///
922 /// let (x, y) = calculate_point();
923 ///
924 /// assert_eq!(x, 4);
925 /// assert_eq!(y, 5);
926 /// ```
927 ///
928 #[stable(feature = "rust1", since = "1.0.0")]
929 mod prim_tuple {}
930
931 #[doc(primitive = "f32")]
932 /// A 32-bit floating point type (specifically, the "binary32" type defined in IEEE 754-2008).
933 ///
934 /// This type can represent a wide range of decimal numbers, like `3.5`, `27`,
935 /// `-113.75`, `0.0078125`, `34359738368`, `0`, `-1`. So unlike integer types
936 /// (such as `i32`), floating point types can represent non-integer numbers,
937 /// too.
938 ///
939 /// However, being able to represent this wide range of numbers comes at the
940 /// cost of precision: floats can only represent some of the real numbers and
941 /// calculation with floats round to a nearby representable number. For example,
942 /// `5.0` and `1.0` can be exactly represented as `f32`, but `1.0 / 5.0` results
943 /// in `0.20000000298023223876953125` since `0.2` cannot be exactly represented
944 /// as `f32`. Note, however, that printing floats with `println` and friends will
945 /// often discard insignificant digits: `println!("{}", 1.0f32 / 5.0f32)` will
946 /// print `0.2`.
947 ///
948 /// Additionally, `f32` can represent some special values:
949 ///
950 /// - −0.0: IEEE 754 floating point numbers have a bit that indicates their sign, so −0.0 is a
951 ///   possible value. For comparison −0.0 = +0.0, but floating point operations can carry
952 ///   the sign bit through arithmetic operations. This means −0.0 × +0.0 produces −0.0 and
953 ///   a negative number rounded to a value smaller than a float can represent also produces −0.0.
954 /// - [∞](#associatedconstant.INFINITY) and
955 ///   [−∞](#associatedconstant.NEG_INFINITY): these result from calculations
956 ///   like `1.0 / 0.0`.
957 /// - [NaN (not a number)](#associatedconstant.NAN): this value results from
958 ///   calculations like `(-1.0).sqrt()`. NaN has some potentially unexpected
959 ///   behavior: it is unequal to any float, including itself! It is also neither
960 ///   smaller nor greater than any float, making it impossible to sort. Lastly,
961 ///   it is considered infectious as almost all calculations where one of the
962 ///   operands is NaN will also result in NaN.
963 ///
964 /// For more information on floating point numbers, see [Wikipedia][wikipedia].
965 ///
966 /// *[See also the `std::f32::consts` module](crate::f32::consts).*
967 ///
968 /// [wikipedia]: https://en.wikipedia.org/wiki/Single-precision_floating-point_format
969 #[stable(feature = "rust1", since = "1.0.0")]
970 mod prim_f32 {}
971
972 #[doc(primitive = "f64")]
973 /// A 64-bit floating point type (specifically, the "binary64" type defined in IEEE 754-2008).
974 ///
975 /// This type is very similar to [`f32`], but has increased
976 /// precision by using twice as many bits. Please see [the documentation for
977 /// `f32`][`f32`] or [Wikipedia on double precision
978 /// values][wikipedia] for more information.
979 ///
980 /// *[See also the `std::f64::consts` module](crate::f64::consts).*
981 ///
982 /// [`f32`]: prim@f32
983 /// [wikipedia]: https://en.wikipedia.org/wiki/Double-precision_floating-point_format
984 #[stable(feature = "rust1", since = "1.0.0")]
985 mod prim_f64 {}
986
987 #[doc(primitive = "i8")]
988 //
989 /// The 8-bit signed integer type.
990 #[stable(feature = "rust1", since = "1.0.0")]
991 mod prim_i8 {}
992
993 #[doc(primitive = "i16")]
994 //
995 /// The 16-bit signed integer type.
996 #[stable(feature = "rust1", since = "1.0.0")]
997 mod prim_i16 {}
998
999 #[doc(primitive = "i32")]
1000 //
1001 /// The 32-bit signed integer type.
1002 #[stable(feature = "rust1", since = "1.0.0")]
1003 mod prim_i32 {}
1004
1005 #[doc(primitive = "i64")]
1006 //
1007 /// The 64-bit signed integer type.
1008 #[stable(feature = "rust1", since = "1.0.0")]
1009 mod prim_i64 {}
1010
1011 #[doc(primitive = "i128")]
1012 //
1013 /// The 128-bit signed integer type.
1014 #[stable(feature = "i128", since = "1.26.0")]
1015 mod prim_i128 {}
1016
1017 #[doc(primitive = "u8")]
1018 //
1019 /// The 8-bit unsigned integer type.
1020 #[stable(feature = "rust1", since = "1.0.0")]
1021 mod prim_u8 {}
1022
1023 #[doc(primitive = "u16")]
1024 //
1025 /// The 16-bit unsigned integer type.
1026 #[stable(feature = "rust1", since = "1.0.0")]
1027 mod prim_u16 {}
1028
1029 #[doc(primitive = "u32")]
1030 //
1031 /// The 32-bit unsigned integer type.
1032 #[stable(feature = "rust1", since = "1.0.0")]
1033 mod prim_u32 {}
1034
1035 #[doc(primitive = "u64")]
1036 //
1037 /// The 64-bit unsigned integer type.
1038 #[stable(feature = "rust1", since = "1.0.0")]
1039 mod prim_u64 {}
1040
1041 #[doc(primitive = "u128")]
1042 //
1043 /// The 128-bit unsigned integer type.
1044 #[stable(feature = "i128", since = "1.26.0")]
1045 mod prim_u128 {}
1046
1047 #[doc(primitive = "isize")]
1048 //
1049 /// The pointer-sized signed integer type.
1050 ///
1051 /// The size of this primitive is how many bytes it takes to reference any
1052 /// location in memory. For example, on a 32 bit target, this is 4 bytes
1053 /// and on a 64 bit target, this is 8 bytes.
1054 #[stable(feature = "rust1", since = "1.0.0")]
1055 mod prim_isize {}
1056
1057 #[doc(primitive = "usize")]
1058 //
1059 /// The pointer-sized unsigned integer type.
1060 ///
1061 /// The size of this primitive is how many bytes it takes to reference any
1062 /// location in memory. For example, on a 32 bit target, this is 4 bytes
1063 /// and on a 64 bit target, this is 8 bytes.
1064 #[stable(feature = "rust1", since = "1.0.0")]
1065 mod prim_usize {}
1066
1067 #[doc(primitive = "reference")]
1068 #[doc(alias = "&")]
1069 #[doc(alias = "&mut")]
1070 //
1071 /// References, both shared and mutable.
1072 ///
1073 /// A reference represents a borrow of some owned value. You can get one by using the `&` or `&mut`
1074 /// operators on a value, or by using a [`ref`](../std/keyword.ref.html) or
1075 /// <code>[ref](../std/keyword.ref.html) [mut](../std/keyword.mut.html)</code> pattern.
1076 ///
1077 /// For those familiar with pointers, a reference is just a pointer that is assumed to be
1078 /// aligned, not null, and pointing to memory containing a valid value of `T` - for example,
1079 /// <code>&[bool]</code> can only point to an allocation containing the integer values `1`
1080 /// ([`true`](../std/keyword.true.html)) or `0` ([`false`](../std/keyword.false.html)), but
1081 /// creating a <code>&[bool]</code> that points to an allocation containing
1082 /// the value `3` causes undefined behaviour.
1083 /// In fact, <code>[Option]\<&T></code> has the same memory representation as a
1084 /// nullable but aligned pointer, and can be passed across FFI boundaries as such.
1085 ///
1086 /// In most cases, references can be used much like the original value. Field access, method
1087 /// calling, and indexing work the same (save for mutability rules, of course). In addition, the
1088 /// comparison operators transparently defer to the referent's implementation, allowing references
1089 /// to be compared the same as owned values.
1090 ///
1091 /// References have a lifetime attached to them, which represents the scope for which the borrow is
1092 /// valid. A lifetime is said to "outlive" another one if its representative scope is as long or
1093 /// longer than the other. The `'static` lifetime is the longest lifetime, which represents the
1094 /// total life of the program. For example, string literals have a `'static` lifetime because the
1095 /// text data is embedded into the binary of the program, rather than in an allocation that needs
1096 /// to be dynamically managed.
1097 ///
1098 /// `&mut T` references can be freely coerced into `&T` references with the same referent type, and
1099 /// references with longer lifetimes can be freely coerced into references with shorter ones.
1100 ///
1101 /// Reference equality by address, instead of comparing the values pointed to, is accomplished via
1102 /// implicit reference-pointer coercion and raw pointer equality via [`ptr::eq`], while
1103 /// [`PartialEq`] compares values.
1104 ///
1105 /// ```
1106 /// use std::ptr;
1107 ///
1108 /// let five = 5;
1109 /// let other_five = 5;
1110 /// let five_ref = &five;
1111 /// let same_five_ref = &five;
1112 /// let other_five_ref = &other_five;
1113 ///
1114 /// assert!(five_ref == same_five_ref);
1115 /// assert!(five_ref == other_five_ref);
1116 ///
1117 /// assert!(ptr::eq(five_ref, same_five_ref));
1118 /// assert!(!ptr::eq(five_ref, other_five_ref));
1119 /// ```
1120 ///
1121 /// For more information on how to use references, see [the book's section on "References and
1122 /// Borrowing"][book-refs].
1123 ///
1124 /// [book-refs]: ../book/ch04-02-references-and-borrowing.html
1125 ///
1126 /// # Trait implementations
1127 ///
1128 /// The following traits are implemented for all `&T`, regardless of the type of its referent:
1129 ///
1130 /// * [`Copy`]
1131 /// * [`Clone`] \(Note that this will not defer to `T`'s `Clone` implementation if it exists!)
1132 /// * [`Deref`]
1133 /// * [`Borrow`]
1134 /// * [`fmt::Pointer`]
1135 ///
1136 /// [`Deref`]: ops::Deref
1137 /// [`Borrow`]: borrow::Borrow
1138 ///
1139 /// `&mut T` references get all of the above except `Copy` and `Clone` (to prevent creating
1140 /// multiple simultaneous mutable borrows), plus the following, regardless of the type of its
1141 /// referent:
1142 ///
1143 /// * [`DerefMut`]
1144 /// * [`BorrowMut`]
1145 ///
1146 /// [`DerefMut`]: ops::DerefMut
1147 /// [`BorrowMut`]: borrow::BorrowMut
1148 /// [bool]: prim@bool
1149 ///
1150 /// The following traits are implemented on `&T` references if the underlying `T` also implements
1151 /// that trait:
1152 ///
1153 /// * All the traits in [`std::fmt`] except [`fmt::Pointer`] (which is implemented regardless of the type of its referent) and [`fmt::Write`]
1154 /// * [`PartialOrd`]
1155 /// * [`Ord`]
1156 /// * [`PartialEq`]
1157 /// * [`Eq`]
1158 /// * [`AsRef`]
1159 /// * [`Fn`] \(in addition, `&T` references get [`FnMut`] and [`FnOnce`] if `T: Fn`)
1160 /// * [`Hash`]
1161 /// * [`ToSocketAddrs`]
1162 /// * [`Send`] \(`&T` references also require <code>T: [Sync]</code>)
1163 ///
1164 /// [`std::fmt`]: fmt
1165 /// [`Hash`]: hash::Hash
1166 #[doc = concat!("[`ToSocketAddrs`]: ", include_str!("../primitive_docs/net_tosocketaddrs.md"))]
1167 ///
1168 /// `&mut T` references get all of the above except `ToSocketAddrs`, plus the following, if `T`
1169 /// implements that trait:
1170 ///
1171 /// * [`AsMut`]
1172 /// * [`FnMut`] \(in addition, `&mut T` references get [`FnOnce`] if `T: FnMut`)
1173 /// * [`fmt::Write`]
1174 /// * [`Iterator`]
1175 /// * [`DoubleEndedIterator`]
1176 /// * [`ExactSizeIterator`]
1177 /// * [`FusedIterator`]
1178 /// * [`TrustedLen`]
1179 /// * [`io::Write`]
1180 /// * [`Read`]
1181 /// * [`Seek`]
1182 /// * [`BufRead`]
1183 ///
1184 /// [`FusedIterator`]: iter::FusedIterator
1185 /// [`TrustedLen`]: iter::TrustedLen
1186 #[doc = concat!("[`Seek`]: ", include_str!("../primitive_docs/io_seek.md"))]
1187 #[doc = concat!("[`BufRead`]: ", include_str!("../primitive_docs/io_bufread.md"))]
1188 #[doc = concat!("[`Read`]: ", include_str!("../primitive_docs/io_read.md"))]
1189 #[doc = concat!("[`io::Write`]: ", include_str!("../primitive_docs/io_write.md"))]
1190 ///
1191 /// Note that due to method call deref coercion, simply calling a trait method will act like they
1192 /// work on references as well as they do on owned values! The implementations described here are
1193 /// meant for generic contexts, where the final type `T` is a type parameter or otherwise not
1194 /// locally known.
1195 #[stable(feature = "rust1", since = "1.0.0")]
1196 mod prim_ref {}
1197
1198 #[doc(primitive = "fn")]
1199 //
1200 /// Function pointers, like `fn(usize) -> bool`.
1201 ///
1202 /// *See also the traits [`Fn`], [`FnMut`], and [`FnOnce`].*
1203 ///
1204 /// [`Fn`]: ops::Fn
1205 /// [`FnMut`]: ops::FnMut
1206 /// [`FnOnce`]: ops::FnOnce
1207 ///
1208 /// Function pointers are pointers that point to *code*, not data. They can be called
1209 /// just like functions. Like references, function pointers are, among other things, assumed to
1210 /// not be null, so if you want to pass a function pointer over FFI and be able to accommodate null
1211 /// pointers, make your type [`Option<fn()>`](core::option#options-and-pointers-nullable-pointers)
1212 /// with your required signature.
1213 ///
1214 /// ### Safety
1215 ///
1216 /// Plain function pointers are obtained by casting either plain functions, or closures that don't
1217 /// capture an environment:
1218 ///
1219 /// ```
1220 /// fn add_one(x: usize) -> usize {
1221 ///     x + 1
1222 /// }
1223 ///
1224 /// let ptr: fn(usize) -> usize = add_one;
1225 /// assert_eq!(ptr(5), 6);
1226 ///
1227 /// let clos: fn(usize) -> usize = |x| x + 5;
1228 /// assert_eq!(clos(5), 10);
1229 /// ```
1230 ///
1231 /// In addition to varying based on their signature, function pointers come in two flavors: safe
1232 /// and unsafe. Plain `fn()` function pointers can only point to safe functions,
1233 /// while `unsafe fn()` function pointers can point to safe or unsafe functions.
1234 ///
1235 /// ```
1236 /// fn add_one(x: usize) -> usize {
1237 ///     x + 1
1238 /// }
1239 ///
1240 /// unsafe fn add_one_unsafely(x: usize) -> usize {
1241 ///     x + 1
1242 /// }
1243 ///
1244 /// let safe_ptr: fn(usize) -> usize = add_one;
1245 ///
1246 /// //ERROR: mismatched types: expected normal fn, found unsafe fn
1247 /// //let bad_ptr: fn(usize) -> usize = add_one_unsafely;
1248 ///
1249 /// let unsafe_ptr: unsafe fn(usize) -> usize = add_one_unsafely;
1250 /// let really_safe_ptr: unsafe fn(usize) -> usize = add_one;
1251 /// ```
1252 ///
1253 /// ### ABI
1254 ///
1255 /// On top of that, function pointers can vary based on what ABI they use. This
1256 /// is achieved by adding the `extern` keyword before the type, followed by the
1257 /// ABI in question. The default ABI is "Rust", i.e., `fn()` is the exact same
1258 /// type as `extern "Rust" fn()`. A pointer to a function with C ABI would have
1259 /// type `extern "C" fn()`.
1260 ///
1261 /// `extern "ABI" { ... }` blocks declare functions with ABI "ABI". The default
1262 /// here is "C", i.e., functions declared in an `extern {...}` block have "C"
1263 /// ABI.
1264 ///
1265 /// For more information and a list of supported ABIs, see [the nomicon's
1266 /// section on foreign calling conventions][nomicon-abi].
1267 ///
1268 /// [nomicon-abi]: ../nomicon/ffi.html#foreign-calling-conventions
1269 ///
1270 /// ### Variadic functions
1271 ///
1272 /// Extern function declarations with the "C" or "cdecl" ABIs can also be *variadic*, allowing them
1273 /// to be called with a variable number of arguments. Normal Rust functions, even those with an
1274 /// `extern "ABI"`, cannot be variadic. For more information, see [the nomicon's section on
1275 /// variadic functions][nomicon-variadic].
1276 ///
1277 /// [nomicon-variadic]: ../nomicon/ffi.html#variadic-functions
1278 ///
1279 /// ### Creating function pointers
1280 ///
1281 /// When `bar` is the name of a function, then the expression `bar` is *not* a
1282 /// function pointer. Rather, it denotes a value of an unnameable type that
1283 /// uniquely identifies the function `bar`. The value is zero-sized because the
1284 /// type already identifies the function. This has the advantage that "calling"
1285 /// the value (it implements the `Fn*` traits) does not require dynamic
1286 /// dispatch.
1287 ///
1288 /// This zero-sized type *coerces* to a regular function pointer. For example:
1289 ///
1290 /// ```rust
1291 /// use std::mem;
1292 ///
1293 /// fn bar(x: i32) {}
1294 ///
1295 /// let not_bar_ptr = bar; // `not_bar_ptr` is zero-sized, uniquely identifying `bar`
1296 /// assert_eq!(mem::size_of_val(&not_bar_ptr), 0);
1297 ///
1298 /// let bar_ptr: fn(i32) = not_bar_ptr; // force coercion to function pointer
1299 /// assert_eq!(mem::size_of_val(&bar_ptr), mem::size_of::<usize>());
1300 ///
1301 /// let footgun = &bar; // this is a shared reference to the zero-sized type identifying `bar`
1302 /// ```
1303 ///
1304 /// The last line shows that `&bar` is not a function pointer either. Rather, it
1305 /// is a reference to the function-specific ZST. `&bar` is basically never what you
1306 /// want when `bar` is a function.
1307 ///
1308 /// ### Traits
1309 ///
1310 /// Function pointers implement the following traits:
1311 ///
1312 /// * [`Clone`]
1313 /// * [`PartialEq`]
1314 /// * [`Eq`]
1315 /// * [`PartialOrd`]
1316 /// * [`Ord`]
1317 /// * [`Hash`]
1318 /// * [`Pointer`]
1319 /// * [`Debug`]
1320 ///
1321 /// [`Hash`]: hash::Hash
1322 /// [`Pointer`]: fmt::Pointer
1323 ///
1324 /// Due to a temporary restriction in Rust's type system, these traits are only implemented on
1325 /// functions that take 12 arguments or less, with the `"Rust"` and `"C"` ABIs. In the future, this
1326 /// may change.
1327 ///
1328 /// In addition, function pointers of *any* signature, ABI, or safety are [`Copy`], and all *safe*
1329 /// function pointers implement [`Fn`], [`FnMut`], and [`FnOnce`]. This works because these traits
1330 /// are specially known to the compiler.
1331 #[stable(feature = "rust1", since = "1.0.0")]
1332 mod prim_fn {}