---

yaml
---
r: 31443
b: refs/heads/dist-snap
c: f1f9066
h: refs/heads/master
i:
  31441: 9b33413
  31439: c8a6c75
v: v3

Author: paulstansifer

[refs]

@@ -7,6 +7,6 @@ refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: d0c6ce338884ee21843f4b40bf6bf18d222ce5df
 refs/heads/incoming: d9317a174e434d4c99fc1a37fd7dc0d2f5328d37
-refs/heads/dist-snap: afd9a75c9ebf56b0a387928cdbef7d086200f534
+refs/heads/dist-snap: f1f9066274114637510a48ab1087750262ae0699
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/dist-snap/doc/tutorial.md

@@ -34,9 +34,8 @@ high-level features include:
 * ***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.
-* ***Trait polymorphism.*** Rust's type system features a unique
-  combination of Java-style interfaces and Haskell-style typeclasses
-  called _traits_.
+* ***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
@@ -2090,9 +2089,9 @@ resource type. Rust has several kinds that can be used as type bounds:
   mutable fields nor shared boxes.
 
 > ***Note:*** Rust type kinds are syntactically very similar to
-> [traits](#traits) when used as type bounds, and can be
-> conveniently thought of as built-in traits. In the future type
-> kinds will actually be traits that the compiler has special
+> [interfaces](#interfaces) when used as type bounds, and can be
+> conveniently thought of as built-in interfaces. In the future type
+> kinds will actually be interfaces that the compiler has special
 > knowledge about.
 
 ## Generic functions and argument-passing
@@ -2389,9 +2388,9 @@ This makes it possible to rebind a variable without actually mutating
 it, which is mostly useful for destructuring (which can rebind, but
 not assign).
 
-# Traits
+# Interfaces
 
-Traits are Rust's take on value polymorphism—the thing that
+Interfaces are Rust's take on value polymorphism—the thing that
 object-oriented languages tend to solve with methods and inheritance.
 For example, writing a function that can operate on multiple types of
 collections.
@@ -2401,27 +2400,27 @@ collections.
 
 ## Declaration
 
-A trait consists of a set of methods. A method is a function that
+An interface consists of a set of methods. A method is a function that
 can be applied to a `self` value and a number of arguments, using the
 dot notation: `self.foo(arg1, arg2)`.
 
-For example, we could declare the trait `to_str` for things that
+For example, we could declare the interface `to_str` for things that
 can be converted to a string, with a single method of the same name:
 
 ~~~~
-trait to_str {
+iface to_str {
     fn to_str() -> ~str;
 }
 ~~~~
 
 ## Implementation
 
-To actually implement an trait for a given type, the `impl` form
+To actually implement an interface for a given type, the `impl` form
 is used. This defines implementations of `to_str` for the `int` and
 `~str` types.
 
 ~~~~
-# trait to_str { fn to_str() -> ~str; }
+# iface to_str { fn to_str() -> ~str; }
 impl of to_str for int {
     fn to_str() -> ~str { int::to_str(self, 10u) }
 }
@@ -2440,13 +2439,13 @@ method that matches the name, and simply calls that.
 
 Implementations are not globally visible. Resolving a method to an
 implementation requires that implementation to be in scope. You can
-import and export implementations using the name of the trait they
+import and export implementations using the name of the interface they
 implement (multiple implementations with the same name can be in scope
 without problems). Or you can give them an explicit name if you
 prefer, using this syntax:
 
 ~~~~
-# trait to_str { fn to_str() -> ~str; }
+# iface to_str { fn to_str() -> ~str; }
 impl nil_to_str of to_str for () {
     fn to_str() -> ~str { ~"()" }
 }
@@ -2462,7 +2461,7 @@ known at compile time, it is possible to specify 'bounds' for type
 parameters.
 
 ~~~~
-# trait to_str { fn to_str() -> ~str; }
+# iface to_str { fn to_str() -> ~str; }
 fn comma_sep<T: to_str>(elts: ~[T]) -> ~str {
     let mut result = ~"", first = true;
     for elts.each |elt| {
@@ -2477,18 +2476,18 @@ fn comma_sep<T: to_str>(elts: ~[T]) -> ~str {
 The syntax for this is similar to the syntax for specifying that a
 parameter type has to be copyable (which is, in principle, another
 kind of bound). By declaring `T` as conforming to the `to_str`
-trait, it becomes possible to call methods from that trait on
+interface, it becomes possible to call methods from that interface on
 values of that type inside the function. It will also cause a
 compile-time error when anyone tries to call `comma_sep` on an array
 whose element type does not have a `to_str` implementation in scope.
 
-## Polymorphic traits
+## Polymorphic interfaces
 
-Traits may contain type parameters. This defines a trait for
+Interfaces may contain type parameters. This defines an interface for
 generalized sequence types:
 
 ~~~~
-trait seq<T> {
+iface seq<T> {
     fn len() -> uint;
     fn iter(fn(T));
 }
@@ -2501,25 +2500,25 @@ impl <T> of seq<T> for ~[T] {
 ~~~~
 
 Note that the implementation has to explicitly declare the its
-parameter `T` before using it to specify its trait type. This is
+parameter `T` before using it to specify its interface type. This is
 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 a trait are in scope in each of the
+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 trait or
+`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 traits
+## The `self` type in interfaces
 
-In a trait, `self` is a special type that you can think of as a
-type parameter. An implementation of the trait for any given type
+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
-trait describes types that support an equality operation:
+interface describes types that support an equality operation:
 
 ~~~~
-trait eq {
+iface eq {
   fn equals(&&other: self) -> bool;
 }
 
@@ -2531,15 +2530,15 @@ impl of eq for int {
 Notice that `equals` takes an `int` argument, rather than a `self` argument, in
 an implementation for type `int`.
 
-## Casting to an trait type
+## Casting to an interface type
 
 The above allows us to define functions that polymorphically act on
-values of *an* unknown type that conforms to a given trait.
+values of *an* unknown type that conforms to a given interface.
 However, consider this function:
 
 ~~~~
 # type circle = int; type rectangle = int;
-# trait drawable { fn draw(); }
+# iface drawable { fn draw(); }
 # impl of drawable for int { fn draw() {} }
 # fn new_circle() -> int { 1 }
 fn draw_all<T: drawable>(shapes: ~[T]) {
@@ -2550,14 +2549,14 @@ fn draw_all<T: drawable>(shapes: ~[T]) {
 ~~~~
 
 You can call that on an array of circles, or an array of squares
-(assuming those have suitable `drawable` traits defined), but not
+(assuming those have suitable `drawable` interfaces defined), but not
 on an array containing both circles and squares.
 
-When this is needed, a trait name can be used as a type, causing
+When this is needed, an interface name can be used as a type, causing
 the function to be written simply like this:
 
 ~~~~
-# trait drawable { fn draw(); }
+# iface drawable { fn draw(); }
 fn draw_all(shapes: ~[drawable]) {
     for shapes.each |shape| { shape.draw(); }
 }
@@ -2572,11 +2571,11 @@ is very similar to the 'vtables' used in most object-oriented
 languages.
 
 To construct such a value, you use the `as` operator to cast a value
-to a trait type:
+to an interface type:
 
 ~~~~
 # type circle = int; type rectangle = int;
-# trait drawable { fn draw(); }
+# iface drawable { fn draw(); }
 # impl of drawable for int { fn draw() {} }
 # fn new_circle() -> int { 1 }
 # fn new_rectangle() -> int { 2 }
@@ -2595,10 +2594,10 @@ Note that the allocation of a box is somewhat more expensive than
 simply using a type parameter and passing in the value as-is, and much
 more expensive than statically resolved method calls.
 
-## Trait-less implementations
+## Interface-less implementations
 
 If you only intend to use an implementation for static overloading,
-and there is no trait available that it conforms to, you are free
+and there is no interface available that it conforms to, you are free
 to leave off the `of` clause.  However, this is only possible when you
 are defining an implementation in the same module as the receiver
 type, and the receiver type is a named type (i.e., an enum or a

branches/dist-snap/mk/tests.mk

@@ -95,9 +95,6 @@ cleantestlibs:
 check: cleantestlibs cleantmptestlogs tidy all check-stage2
 	$(Q)$(S)src/etc/check-summary.py tmp/*.log
 
-check-notidy: cleantestlibs cleantmptestlogs all check-stage2
-	$(Q)$(S)src/etc/check-summary.py tmp/*.log
-
 check-full: cleantestlibs cleantmptestlogs tidy \
             all check-stage1 check-stage2 check-stage3
 	$(Q)$(S)src/etc/check-summary.py tmp/*.log

branches/dist-snap/src/libcore/arc.rs

@@ -3,9 +3,10 @@
  * share immutable data between tasks.
  */
 
+import comm::{port, chan, methods};
 import sys::methods;
 
-export arc, get, clone;
+export arc, get, clone, shared_arc, get_arc;
 
 export exclusive, methods;
 
@@ -121,6 +122,49 @@ impl methods<T: send> for exclusive<T> {
     }
 }
 
+// Convenience code for sharing arcs between tasks
+
+type get_chan<T: const send> = chan<chan<arc<T>>>;
+
+// (terminate, get)
+type shared_arc<T: const send> = (shared_arc_res, get_chan<T>);
+
+class shared_arc_res {
+   let c: comm::chan<()>;
+   new(c: comm::chan<()>) { self.c = c; }
+   drop { self.c.send(()); }
+}
+
+fn shared_arc<T: send const>(-data: T) -> shared_arc<T> {
+    let a = arc::arc(data);
+    let p = port();
+    let c = chan(p);
+    do task::spawn() |move a| {
+        let mut live = true;
+        let terminate = port();
+        let get = port();
+
+        c.send((chan(terminate), chan(get)));
+
+        while live {
+            alt comm::select2(terminate, get) {
+              either::left(()) { live = false; }
+              either::right(cc) {
+                comm::send(cc, arc::clone(&a));
+              }
+            }
+        }
+    };
+    let (terminate, get) = p.recv();
+    (shared_arc_res(terminate), get)
+}
+
+fn get_arc<T: send const>(c: get_chan<T>) -> arc::arc<T> {
+    let p = port();
+    c.send(chan(p));
+    p.recv()
+}
+
 #[cfg(test)]
 mod tests {
     import comm::*;
@@ -152,6 +196,25 @@ mod tests {
         log(info, arc_v);
     }
 
+    #[test]
+    fn auto_share_arc() {
+        let v = ~[1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
+        let (_res, arc_c) = shared_arc(v);
+
+        let p = port();
+        let c = chan(p);
+
+        do task::spawn() {
+            let arc_v = get_arc(arc_c);
+            let v = *get(&arc_v);
+            assert v[2] == 3;
+
+            c.send(());
+        };
+
+        assert p.recv() == ();
+    }
+
     #[test]
     #[ignore] // this can probably infinite loop too.
     fn exclusive_arc() {

branches/dist-snap/src/libcore/cmp.rs

@@ -1,10 +1,10 @@
 /// Interfaces used for comparison.
 
-trait ord {
-    pure fn lt(&&other: self) -> bool;
+iface ord {
+    fn lt(&&other: self) -> bool;
 }
 
-trait eq {
-    pure fn eq(&&other: self) -> bool;
+iface eq {
+    fn eq(&&other: self) -> bool;
 }
 

branches/dist-snap/src/libcore/core.rc

@@ -161,7 +161,6 @@ mod tuple;
 
 // Ubiquitous-utility-type modules
 
-mod ops;
 mod cmp;
 mod num;
 mod hash;

branches/dist-snap/src/libcore/core.rs

@@ -30,8 +30,6 @@ import float::num;
 import f32::num;
 import f64::num;
 import num::num;
-import ops::{const, copy, send, owned};
-import ops::{add, sub, mul, div, modulo, neg, bitops, index};
 
 export path, option, some, none, unreachable;
 export extensions;
@@ -44,9 +42,6 @@ export immutable_copyable_vector, iter_trait_extensions, vec_concat;
 export base_iter, copyable_iter, extended_iter;
 export tuple_ops, extended_tuple_ops;
 export ptr;
-// The following exports are the core operators and kinds
-export const, copy, send, owned;
-export add, sub, mul, div, modulo, neg, bitops, index;
 
 // Export the log levels as global constants. Higher levels mean
 // more-verbosity. Error is the bottom level, default logging level is