---

yaml
---
r: 22662
b: refs/heads/master
c: 9b02acb
h: refs/heads/master
v: v3

Author: dgryski

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: a57087e03271c7ad35b173acb6da136da541618c
+refs/heads/master: 9b02acbc5d26fcd6dc950115b0abb74cb9374725
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
 refs/heads/try: ffbe0e0e00374358b789b0037bcb3a577cd218be

trunk/AUTHORS.txt

@@ -39,7 +39,6 @@ Haitao Li <[email protected]>
 Ian D. Bollinger <[email protected]>
 Jacob Parker <[email protected]>
 Jason Orendorff <[email protected]>
-Jed Davis <[email protected]>
 Jeff Balogh <[email protected]>
 Jeff Muizelaar <[email protected]>
 Jeff Olson <[email protected]>

trunk/Makefile.in

@@ -129,15 +129,13 @@ LIBSYNTAX_DSYM_GLOB :=$(call CFG_LIB_DSYM_GLOB,syntax)
 
 # version-string calculation
 CFG_GIT_DIR := $(CFG_SRC_DIR).git
-CFG_RELEASE = 0.3.1
+CFG_RELEASE = 0.3
 CFG_VERSION = $(CFG_RELEASE)
 
 ifneq ($(wildcard $(CFG_GIT)),)
 ifneq ($(wildcard $(CFG_GIT_DIR)),)
     CFG_VERSION += $(shell git --git-dir=$(CFG_GIT_DIR) log -1 \
                      --pretty=format:'(%h %ci)')
-    CFG_VER_HASH = $(shell git --git-dir=$(CFG_GIT_DIR) log -1 \
-                     --pretty=format:'%H')
 endif
 endif
 

trunk/doc/rust.css

@@ -2,8 +2,6 @@ body {
   padding: 1em;
   margin: 0;
   font-family: "Helvetica Neue", Helvetica, sans-serif;
-  background-color: white;
-  color: black;
 }
 
 body {
@@ -60,22 +58,6 @@ h1.title {
   background-position: right;
 }
 
-#versioninfo {
-  position: fixed;
-  bottom: 0px;
-  right: 0px;
-
-  background-color: white;
-  border-left: solid 1px black;
-  border-top: solid 1px black;
-  padding: 0.5em;
-}
-
-a.lessimportant {
-  color: gray;
-  font-size: 60%;
-}
-
 blockquote {
     color: black;
     border-left: solid 1px silver;

trunk/doc/rust.md

@@ -422,7 +422,7 @@ type_path_tail : '<' type_expr [ ',' type_expr ] + '>'
 
 A _path_ is a sequence of one or more path components _logically_ separated by
 a namespace qualifier (`::`). If a path consists of only one component, it may
-refer to either an [item](#items) or a [slot](#memory-slots) in a local
+refer to either an [item](#items) or a [slot](#slot-declarations) in a local
 control scope. If a path has multiple components, it refers to an item.
 
 Every item has a _canonical path_ within its crate, but the path naming an
@@ -831,9 +831,9 @@ Here, `foo` imports `t`, but not `a`, `b`, and `c`.
 A _function item_ defines a sequence of [statements](#statements) and an
 optional final [expression](#expressions) associated with a name and a set of
 parameters. Functions are declared with the keyword `fn`. Functions declare a
-set of *input* [*slots*](#memory-slots) as parameters, through which the
-caller passes arguments into the function, and an *output*
-[*slot*](#memory-slots) through which the function passes results back to
+set of *input [slots](#slot-declarations)* as parameters, through which the
+caller passes arguments into the function, and an *output
+[slot](#slot-declarations)* through which the function passes results back to
 the caller.
 
 A function may also be copied into a first class *value*, in which case the
@@ -1251,8 +1251,8 @@ laid out in the same order.
 
 ### Traits
 
-A _trait item_ describes a set of method types. [_implementation
-items_](#implementations) can be used to provide implementations of
+A _trait item_ describes a set of method types. _[implementation
+items](#implementations)_ can be used to provide implementations of
 those methods for a specific type.
 
 ~~~~
@@ -1624,7 +1624,7 @@ rec_expr : '{' ident ':' expr
                [ "with" expr ] '}'
 ~~~~~~~~
 
-A [_record_](#record-types) _expression_ is one or more comma-separated
+A _[record](#record-types) expression_ is one or more comma-separated
 name-value pairs enclosed by braces. A fieldname can be any identifier
 (including keywords), and is separated from its value expression by a
 colon. To indicate that a field is mutable, the `mut` keyword is
@@ -1689,7 +1689,7 @@ expression on the left of the dot.
 vec_expr : '[' "mut" ? [ expr [ ',' expr ] * ] ? ']'
 ~~~~~~~~
 
-A [_vector_](#vector-types) _expression_ is written by enclosing zero or
+A _[vector](#vector-types) expression_ is written by enclosing zero or
 more comma-separated expressions of uniform type in square brackets.
 The keyword `mut` can be written after the opening bracket to
 indicate that the elements of the resulting vector may be mutated.

trunk/doc/tutorial.md

@@ -15,31 +15,28 @@ the whole language, though not with the depth and precision of the
 
 Rust is a systems programming language with a focus on type safety,
 memory safety, concurrency and performance. It is intended for writing
-large, high-performance applications while preventing several classes
+large, high performance applications while preventing several classes
 of errors commonly found in languages like C++. Rust has a
-sophisticated memory model that makes possible many of the efficient
-data structures used in C++, while disallowing invalid memory accesses
-that would otherwise cause segmentation faults. Like other systems
-languages, it is statically typed and compiled ahead of time.
+sophisticated memory model that enables many of the efficient data
+structures used in C++ while disallowing invalid memory access that
+would otherwise cause segmentation faults. Like other systems
+languages it is statically typed and compiled ahead of time.
 
-As a multi-paradigm language, Rust supports writing code in
-procedural, functional and object-oriented styles. Some of its nice
+As a multi-paradigm language it has strong support for writing code in
+procedural, functional and object-oriented styles. Some of it's nice
 high-level features include:
 
-* ***Pattern matching and algebraic data types (enums).*** Common in
-  functional languages, pattern matching on ADTs provides a compact
-  and expressive way to encode program logic.
-* ***Task-based concurrency.*** Rust uses lightweight tasks that do
-  not share memory.
-* ***Higher-order functions.*** Rust functions may take closures as
-  arguments or return closures as return values.  Closures in Rust are
-  very powerful and used pervasively.
-* ***Interface polymorphism.*** Rust's type system features a unique
-  combination of Java-style interfaces and Haskell-style typeclasses.
-* ***Parametric polymorphism (generics).*** Functions and types can be
-  parameterized over type variables with optional type constraints.
-* ***Type inference.*** Type annotations on local variable
-  declarations can be omitted.
+* Pattern matching and algebraic data types (enums) - common in functional
+  languages, pattern matching on ADTs provides a compact and expressive
+  way to encode program logic
+* Task-based concurrency - Rust uses lightweight tasks that do not share
+  memory
+* Higher-order functions - Closures in Rust are very powerful and used
+  pervasively
+* Polymorphism - Rust's type system features a unique combination of
+  Java-style interfaces and Haskell-style typeclasses
+* Generics - Functions and types can be parameterized over generic
+  types with optional type constraints
 
 ## First impressions
 
@@ -232,7 +229,7 @@ into an error.
 
 ## Anatomy of a Rust program
 
-In its simplest form, a Rust program is a `.rs` file with some
+In its simplest form, a Rust program is simply a `.rs` file with some
 types and functions defined in it. If it has a `main` function, it can
 be compiled to an executable. Rust does not allow code that's not a
 declaration to appear at the top level of the file—all statements must
@@ -1184,59 +1181,61 @@ several of Rust's unique features as we encounter them.
 
 Rust has three competing goals that inform its view of memory:
 
-* Memory safety: memory that is managed by and is accessible to the
-  Rust language must be guaranteed to be valid; under normal
-  circumstances it must be impossible for Rust to trigger a
-  segmentation fault or leak memory
-* Performance: high-performance low-level code must be able to employ
-  a number of allocation strategies; low-performance high-level code
-  must be able to employ a single, garbage-collection-based, heap
-  allocation strategy
-* Concurrency: Rust must maintain memory safety guarantees, even for
-  code running in parallel
+* Memory safety - memory that is managed by and is accessible to
+  the Rust language must be guaranteed to be valid. Under normal
+  circumstances it is impossible for Rust to trigger a segmentation
+  fault or leak memory
+* Performance - high-performance low-level code tends to employ
+  a number of allocation strategies. low-performance high-level
+  code often uses a single, GC-based, heap allocation strategy
+* Concurrency - Rust must maintain memory safety guarantees even
+  for code running in parallel
 
 ## How performance considerations influence the memory model
 
-Most languages that offer strong memory safety guarantees rely upon a
-garbage-collected heap to manage all of the objects. This approach is
-straightforward both in concept and in implementation, but has
-significant costs. Languages that take this approach tend to
+Many languages that ofter the kinds of memory safety guarentees that
+Rust does have a single allocation strategy: objects live on the heap,
+live for as long as they are needed, and are periodically garbage
+collected. This is very straightforword both conceptually and in
+implementation, but has very significant costs. Such languages tend to
 aggressively pursue ways to ameliorate allocation costs (think the
-Java Virtual Machine). Rust supports this strategy with _shared
-boxes_: memory allocated on the heap that may be referred to (shared)
+Java virtual machine). Rust supports this strategy with _shared
+boxes_, memory allocated on the heap that may be referred to (shared)
 by multiple variables.
 
-By comparison, languages like C++ offer very precise control over
-where objects are allocated. In particular, it is common to put them
-directly on the stack, avoiding expensive heap allocation. In Rust
-this is possible as well, and the compiler will use a clever _pointer
-lifetime analysis_ to ensure that no variable can refer to stack
+In comparison, languages like C++ offer a very precise control over
+where objects are allocated. In particular, it is common to put
+them directly on the stack, avoiding expensive heap allocation. In
+Rust this is possible as well, and the compiler will use a clever
+lifetime analysis to ensure that no variable can refer to stack
 objects after they are destroyed.
 
 ## How concurrency considerations influence the memory model
 
-Memory safety in a concurrent environment involves avoiding race
+Memory safety in a concurrent environment tends to mean avoiding race
 conditions between two threads of execution accessing the same
-memory. Even high-level languages often require programmers to
-correctly employ locking to ensure that a program is free of races.
-
-Rust starts from the position that memory cannot be shared between
-tasks. Experience in other languages has proven that isolating each
-task's heap from the others is a reliable strategy and one that is
-easy for programmers to reason about. Heap isolation has the
-additional benefit that garbage collection must only be done
-per-heap. Rust never "stops the world" to garbage-collect memory.
-
-Complete isolation of heaps between tasks implies that any data
-transferred between tasks must be copied. While this is a fine and
-useful way to implement communication between tasks, it is also very
-inefficient for large data structures.  Because of this, Rust also
-employs a global _exchange heap_. Objects allocated in the exchange
-heap have _ownership semantics_, meaning that there is only a single
-variable that refers to them. For this reason, they are referred to as
-_unique boxes_. All tasks may allocate objects on the exchange heap,
-then transfer ownership of those objects to other tasks, avoiding
-expensive copies.
+memory. Even high-level languages frequently avoid solving this
+problem, requiring programmers to correctly employ locking to unsure
+their program is free of races.
+
+Rust starts from the position that memory simply cannot be shared
+between tasks. Experience in other languages has proven that isolating
+each tasks' heap from each other is a reliable strategy and one that
+is easy for programmers to reason about. Having isolated heaps
+additionally means that garbage collection must only be done
+per-heap. Rust never 'stops the world' to garbage collect memory.
+
+If Rust tasks have completely isolated heaps then that seems to imply
+that any data transferred between them must be copied. While this
+is a fine and useful way to implement communication between tasks,
+it is also very inefficient for large data structures.
+
+Because of this Rust also introduces a global "exchange heap". Objects
+allocated here have _ownership semantics_, meaning that there is only
+a single variable that refers to them. For this reason they are
+refered to as _unique boxes_. All tasks may allocate objects on this
+heap, then transfer ownership of those allocations to other tasks,
+avoiding expensive copies.
 
 ## What to be aware of
 
@@ -1250,11 +1249,11 @@ of each is key to using Rust effectively.
 # Boxes and pointers
 
 In contrast to a lot of modern languages, aggregate types like records
-and enums are _not_ represented as pointers to allocated memory in
-Rust. They are, as in C and C++, represented directly. This means that
-if you `let x = {x: 1f, y: 1f};`, you are creating a record on the
-stack. If you then copy it into a data structure, the whole record is
-copied, not just a pointer.
+and enums are not represented as pointers to allocated memory. They
+are, like in C and C++, represented directly. This means that if you
+`let x = {x: 1f, y: 1f};`, you are creating a record on the stack. If
+you then copy it into a data structure, the whole record is copied,
+not just a pointer.
 
 For small records like `point`, this is usually more efficient than
 allocating memory and going through a pointer. But for big records, or
@@ -1860,7 +1859,7 @@ like methods named 'new' and 'drop', but without 'fn', and without arguments
 for drop.
 
 In the constructor, the compiler will enforce that all fields are initialized
-before doing anything that might allow them to be accessed. This includes
+before doing anything which might allow them to be accessed. This includes
 returning from the constructor, calling any method on 'self', calling any
 function with 'self' as an argument, or taking a reference to 'self'. Mutation
 of immutable fields is possible only in the constructor, and only before doing
@@ -2505,31 +2504,6 @@ needed because it could also, for example, specify an implementation
 of `seq<int>`—the `of` clause *refers* to a type, rather than defining
 one.
 
-The type parameters bound by an iface are in scope in each of the
-method declarations. So, re-declaring the type parameter
-`T` as an explicit type parameter for `len` -- in either the iface or
-the impl -- would be a compile-time error.
-
-## The `self` type in interfaces
-
-In an interface, `self` is a special type that you can think of as a
-type parameter. An implementation of the interface for any given type
-`T` replaces the `self` type parameter with `T`. The following
-interface describes types that support an equality operation:
-
-~~~~
-iface eq {
-  fn equals(&&other: self) -> bool;
-}
-
-impl of eq for int {
-  fn equals(&&other: int) -> bool { other == self }
-}
-~~~~
-
-Notice that `equals` takes an `int` argument, rather than a `self` argument, in
-an implementation for type `int`.
-
 ## Casting to an interface type
 
 The above allows us to define functions that polymorphically act on
@@ -2960,9 +2934,9 @@ other. The function `task::spawn_listener()` supports this pattern. We'll look
 briefly at how it is used.
 
 To see how `spawn_listener()` works, we will create a child task
-that receives `uint` messages, converts them to a string, and sends
+which receives `uint` messages, converts them to a string, and sends
 the string in response.  The child terminates when `0` is received.
-Here is the function that implements the child task:
+Here is the function which implements the child task:
 
 ~~~~
 # import comm::{port, chan, methods};