---

yaml
---
r: 35917
b: refs/heads/try2
c: c33bff9
h: refs/heads/master
i:
  35915: b5eb403
v: v3

Author: Daniel Patterson

[refs]

@@ -5,7 +5,7 @@ refs/heads/snap-stage3: eb8fd119c65c67f3b1b8268cc7341c22d39b7b61
 refs/heads/try: d324a424d8f84b1eb049b12cf34182bda91b0024
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
-refs/heads/try2: 91315c3c2f2b07cc090fa9d1a69aa389f3c605c2
+refs/heads/try2: c33bff955707d496d675126433627297487daa25
 refs/heads/incoming: d9317a174e434d4c99fc1a37fd7dc0d2f5328d37
 refs/heads/dist-snap: 22efa39382d41b084fde1719df7ae8ce5697d8c9
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596

branches/try2/doc/rust.md

@@ -388,10 +388,11 @@ Examples of floating-point literals of various forms:
 12E+99_f64;                        // type f64
 ~~~~
 
-##### Unit and boolean literals
+##### Nil and boolean literals
 
-The _unit value_, the only value of the type that has the same name, is written as `()`.
-The two values of the boolean type are written `true` and `false`.
+The _nil value_, the only value of the type by the same name, is
+written as `()`. The two values of the boolean type are written `true`
+and `false`.
 
 ### Symbols
 
@@ -500,13 +501,14 @@ only be invoked in expression position.
 any token other than a delimiter or `$`.)
 
 Macro invocations are looked up by name, and each macro rule is tried in turn;
-the first successful match is transcribed. The matching and transcription
+the first successful match is transcribed. The matching and transcribing
 processes are closely related, and will be described together:
 
 ### Macro By Example
 
-The macro expander matches and transcribes every token that does not begin with a `$` literally, including delimiters.
-For parsing reasons, delimiters must be balanced, but they are otherwise not special.
+Everything that does not begin with a `$` is matched and transcirbed
+literally, including delimiters. For parsing reasons, they must be matched,
+but they are otherwise not special.
 
 In the matcher, `$` _name_ `:` _designator_ matches the nonterminal in the
 Rust syntax named by _designator_. Valid designators are `item`, `block`,
@@ -515,11 +517,11 @@ are the right-hand side and the left-hand side respectively of the `=>` in
 macro rules. In the transcriber, the designator is already known, and so only
 the name of a matched nonterminal comes after the dollar sign.
 
-In both the matcher and transcriber, the Kleene star-like operator indicates repetition.
-The Kleene star operator consists of `$` and parens, optionally followed by a separator token, followed by `*` or `+`.
-`*` means zero or more repetitions, `+` means at least one repetition.
-The parens are not matched or transcribed.
-On the matcher side, a name is bound to _all_ of the names it
+In bothe the matcher and transcriber, the Kleene star-like operator,
+consisting of `$` and parens, optionally followed by a separator token,
+followed by `*` or `+`, indicates repetition. (`*` means zero or more
+repetitions, `+` means at least one repetition. The parens are not matched or
+transcribed). On the matcher side, a name is bound to _all_ of the names it
 matches, in a structure that mimics the structure of the repetition
 encountered on a successful match. The job of the transcriber is to sort that
 structure out.
@@ -548,34 +550,41 @@ Rust syntax is restricted in two ways:
 1. The parser will always parse as much as possible. If it attempts to match
 `$i:expr [ , ]` against `8 [ , ]`, it will attempt to parse `i` as an array
 index operation and fail. Adding a separator can solve this problem.
-2. The parser must have eliminated all ambiguity by the time it reaches a `$` _name_ `:` _designator_.
-This requirement most often affects name-designator pairs when they occur at the beginning of, or immediately after, a `$(...)*`; requiring a distinctive token in front can solve the problem.
+2. The parser must have eliminated all ambiguity by the time it reaches a
+`$` _name_ `:` _designator_. This most often affects them when they occur in
+the beginning of, or immediately after, a `$(...)*`; requiring a distinctive
+token in front can solve the problem.
 
 
 ## Syntax extensions useful for the macro author
 
 * `log_syntax!` : print out the arguments at compile time
-* `trace_macros!` : supply `true` or `false` to enable or disable printing of the macro expansion process.
-* `ident_to_str!` : turn the identifier argument into a string literal
-* `concat_idents!` : create a new identifier by concatenating the arguments
+* `trace_macros!` : supply `true` or `false` to enable or disable printing
+of the macro expansion process.
+* `ident_to_str!` : turns the identifier argument into a string literal
+* `concat_idents!` : creates a new identifier by concatenating its arguments
 
 
 
 # Crates and source files
 
-Rust is a *compiled* language.
-Its semantics obey a *phase distinction* between compile-time and run-time.
-Those semantic rules that have a *static interpretation* govern the success or failure of compilation.
-We refer to these rules as "static semantics".
-Semantic rules called "dynamic semantics" govern the behavior of programs at run-time.
-A program that fails to compile due to violation of a compile-time rule has no defined dynamic semantics; the compiler should halt with an error report, and produce no executable artifact.
+Rust is a *compiled* language. Its semantics are divided along a
+*phase distinction* between compile-time and run-time. Those semantic
+rules that have a *static interpretation* govern the success or failure
+of compilation. A program that fails to compile due to violation of a
+compile-time rule has no defined semantics at run-time; the compiler should
+halt with an error report, and produce no executable artifact.
 
-The compilation model centres on artifacts called _crates_.
-Each compilation processes a single crate in source form, and if successful, produces a single crate in binary form: either an executable or a library.
+The compilation model centres on artifacts called _crates_. Each compilation
+is directed towards a single crate in source form, and if successful,
+produces a single crate in binary form: either an executable or a library.
 
-A _crate_ is a unit of compilation and linking, as well as versioning, distribution and runtime loading.
-A crate contains a _tree_ of nested [module](#modules) scopes.
-The top level of this tree is a module that is anonymous (from the point of view of paths within the module) and any item within a crate has a canonical [module path](#paths) denoting its location within the crate's module tree.
+A _crate_ is a unit of compilation and linking, as well as versioning,
+distribution and runtime loading. A crate contains a _tree_ of nested
+[module](#modules) scopes. The top level of this tree is a module that is
+anonymous -- from the point of view of paths within the module -- and any item
+within a crate has a canonical [module path](#paths) denoting its location
+within the crate's module tree.
 
 Crates are provided to the Rust compiler through two kinds of file:
 
@@ -585,15 +594,18 @@ Crates are provided to the Rust compiler through two kinds of file:
 > **Note:** The functionality of crate files will be merged into source files in future versions of Rust.
 > The separate processing of crate files, both their grammar and file extension, will be removed.
 
-The Rust compiler is always invoked with a single crate file as input, and always produces a single output crate.
+The Rust compiler is always invoked with a single input file, and always
+produces a single output crate.
 
 When the Rust compiler is invoked with a crate file, it reads the _explicit_
 definition of the crate it's compiling from that file, and populates the
 crate with modules derived from all the source files referenced by the
 crate, reading and processing all the referenced modules at once.
 
-When the Rust compiler is invoked with a source file, it creates an _implicit_ crate and treats the source file as if it is the sole module populating this explicit crate.
-The module name is derived from the source file name, with the `.rs` extension removed.
+When the Rust compiler is invoked with a source file, it creates an
+_implicit_ crate and treats the source file as though it was referenced as
+the sole module populating this implicit crate. The module name is derived
+from the source file name, with the `.rs` extension removed.
 
 ## Crate files
 
@@ -650,8 +662,10 @@ containing source files and/or further subdirectories. The filesystem
 directory associated with a `dir_directive` module can either be explicit,
 or if omitted, is implicitly the same name as the module.
 
-A `source_directive` references a source file, either explicitly or implicitly, by combining the module name with the file extension `.rs`.
-The module contained in that source file is bound to the module path formed by the `dir_directive` modules containing the `source_directive`.
+A `source_directive` references a source file, either explicitly or
+implicitly by combining the module name with the file extension `.rs`.  The
+module contained in that source file is bound to the module path formed by
+the `dir_directive` modules containing the `source_directive`.
 
 ## Source files
 
@@ -661,8 +675,9 @@ location of which -- in the module tree of the current crate -- is defined
 from outside the source file: either by an explicit `source_directive` in
 a referencing crate file, or by the filename of the source file itself.
 
-A source file that contains a `main` function can be compiled to an executable.
-If a `main` function is present, its return type must be [`unit`](#primitive-types) and it must take no arguments.
+A source file that contains a `main` function can be compiled to an
+executable. If a `main` function is present,
+its return type must be [`nil`](#primitive-types) and it must take no arguments.
 
 # Items and attributes
 
@@ -1483,10 +1498,10 @@ A temporary's lifetime equals the largest lifetime of any borrowed pointer that
 
 A _literal expression_ consists of one of the [literal](#literals)
 forms described earlier. It directly describes a number, character,
-string, boolean value, or the unit value.
+string, boolean value, or the nil value.
 
 ~~~~~~~~ {.literals}
-();        // unit type
+();        // nil type
 "hello";   // string type
 '5';       // character type
 5;         // integer type
@@ -1851,7 +1866,7 @@ operators may be composed with the `=` operator. The expression `lval
 OP= val` is equivalent to `lval = lval OP val`. For example, `x = x +
 1` may be written as `x += 1`.
 
-Any such expression always has the [`unit`](#primitive-types) type.
+Any such expression always has the [`nil`](#primitive-types) type.
 
 #### Operator precedence
 
@@ -2403,8 +2418,11 @@ types. User-defined types have limited capabilities.
 
 The primitive types are the following:
 
-* The "unit" type `()`, having the single "unit" value `()` (occasionally called "nil").
-  ^[The "unit" value `()` is *not* a sentinel "null pointer" value for reference slots; the "unit" type is the implicit return type from functions otherwise lacking a return type, and can be used in other contexts (such as message-sending or type-parametric code) as a zero-size type.]
+* The "nil" type `()`, having the single "nil" value `()`.^[The "nil" value
+  `()` is *not* a sentinel "null pointer" value for reference slots; the "nil"
+  type is the implicit return type from functions otherwise lacking a return
+  type, and can be used in other contexts (such as message-sending or
+  type-parametric code) as a zero-size type.]
 * The boolean type `bool` with values `true` and `false`.
 * The machine types.
 * The machine-dependent integer and floating-point types.

branches/try2/doc/tutorial.md

@@ -216,7 +216,7 @@ while count < 10 {
 
 Although Rust can almost always infer the types of local variables, you
 can specify a variable's type by following it with a colon, then the type
-name. 
+name.
 
 ~~~~
 let monster_size: float = 57.8;
@@ -381,6 +381,10 @@ of:
 `[mut T]`                 Mutable vector with unknown size
 ------------------------- -----------------------------------------------
 
+> ***Note***: In the future, mutability for vectors may be defined by
+> the slot that contains the vector, not the type of the vector itself,
+> deprecating [mut T] syntax.
+
 In function types, the return type is specified with an arrow, as in
 the type `fn() -> bool` or the function declaration `fn foo() -> bool
 { }`.  For functions that do not return a meaningful value, you can
@@ -1951,7 +1955,7 @@ trait Printable {
 ~~~~
 
 Traits may be implemented for specific types with [impls]. An impl
-that implements a trait includes the name of the trait at the start of 
+that implements a trait includes the name of the trait at the start of
 the definition, as in the following impls of `Printable` for `int`
 and `~str`.