doc: Remove the section on modes from the tutorial
This commit is contained in:
parent
df34fe917a
commit
4fc164a549
@ -1547,98 +1547,6 @@ fn contains(v: ~[int], elt: int) -> bool {
|
||||
|
||||
`for` syntax only works with stack closures.
|
||||
|
||||
# Argument passing
|
||||
|
||||
Rust datatypes are not trivial to copy (the way, for example,
|
||||
JavaScript values can be copied by simply taking one or two machine
|
||||
words and plunking them somewhere else). Shared boxes require
|
||||
reference count updates, and big records, enums, or unique pointers require
|
||||
an arbitrary amount of data to be copied (plus updating the reference
|
||||
counts of shared boxes hanging off them).
|
||||
|
||||
For this reason, the default calling convention for Rust functions
|
||||
leaves ownership of the arguments with the caller. The caller
|
||||
guarantees that the arguments will outlive the call, the callee merely
|
||||
gets access to them.
|
||||
|
||||
## Safe references
|
||||
|
||||
*This system has recently changed. An explanation is forthcoming.*
|
||||
|
||||
## Other uses of safe references
|
||||
|
||||
Safe references are not only used for argument passing. When you
|
||||
destructure on a value in a `match` expression, or loop over a vector
|
||||
with `for`, variables bound to the inside of the given data structure
|
||||
will use safe references, not copies. This means such references are
|
||||
very cheap, but you'll occasionally have to copy them to ensure
|
||||
safety.
|
||||
|
||||
~~~~
|
||||
let mut my_rec = {a: 4, b: ~[1, 2, 3]};
|
||||
match my_rec {
|
||||
{a, b} => {
|
||||
log(info, b); // This is okay
|
||||
my_rec = {a: a + 1, b: b + ~[a]};
|
||||
log(info, b); // Here reference b has become invalid
|
||||
}
|
||||
}
|
||||
~~~~
|
||||
|
||||
It's unsafe to dereference `b` in the second `log` expression, because `b` is
|
||||
a _pointer_ to the inside of `my_rec`, and the assignment statement has
|
||||
allocated a new record and assigned `my_rec` to point to it. Thus, the old
|
||||
contents of `my_rec` are no longer live, and `b` is dangling at this point.
|
||||
The borrow-checking analysis inside the compiler recognizes this situation
|
||||
and rejects the program.
|
||||
|
||||
## Argument passing styles
|
||||
|
||||
The fact that arguments are conceptually passed by safe reference does
|
||||
not mean all arguments are passed by pointer. Composite types like
|
||||
records and enums *are* passed by pointer, but single-word values, like
|
||||
integers and pointers, are simply passed by value. Most of the time,
|
||||
the programmer does not have to worry about this, as the compiler will
|
||||
simply pick the most efficient passing style. There is one exception,
|
||||
which will be described in the section on [generics](#generics).
|
||||
|
||||
To explicitly set the passing-style for a parameter, you prefix the
|
||||
argument name with a sigil. There are three special passing styles that
|
||||
are often useful. The first is by-mutable-pointer, written with a
|
||||
single `&`:
|
||||
|
||||
~~~~
|
||||
fn vec_push(&v: ~[int], elt: int) {
|
||||
v += ~[elt];
|
||||
}
|
||||
~~~~
|
||||
|
||||
This allows the function to mutate the value of the argument, *in the
|
||||
caller's context*. Clearly, you are only allowed to pass things that
|
||||
can actually be mutated to such a function.
|
||||
|
||||
Then there is the by-copy style, written `+`. This indicates that the
|
||||
function wants to take ownership of the argument value. If the caller
|
||||
does not use the argument after the call, it will be 'given' to the
|
||||
callee. Otherwise a copy will be made. This mode is mostly used for
|
||||
functions that construct data structures. The argument will end up
|
||||
being owned by the data structure, so if that can be done without a
|
||||
copy, that's a win.
|
||||
|
||||
~~~~
|
||||
type person = {name: ~str, address: ~str};
|
||||
fn make_person(+name: ~str, +address: ~str) -> person {
|
||||
return {name: name, address: address};
|
||||
}
|
||||
~~~~
|
||||
|
||||
Finally there is by-move style, written `-`. This indicates that the
|
||||
function will take ownership of the argument, like with by-copy style,
|
||||
but a copy must not be made. The caller is (statically) obliged to not
|
||||
use the argument after the call; it is de-initialized as part of the
|
||||
call. This is used to support ownership-passing in the presence of
|
||||
non-copyable types.
|
||||
|
||||
# Generics
|
||||
|
||||
## Generic functions
|
||||
|
Loading…
x
Reference in New Issue
Block a user