Rust updates

[bearophile]

On Reddit they are currently discussing again about the Rust 
language, and about the browser prototype written in Rust, named 
"Servo" (https://github.com/mozilla/servo ):
http://www.reddit.com/r/programming/comments/w6h7x/the_state_of_servo_a_mozilla_experiment_in/


So I've taken another look at the Rust tutorial:
http://dl.rust-lang.org/doc/tutorial.html

and I've seen Rust is quite more defined compared to the last two 
times I've read about it. So below I put more extracts from the 
tutorial, with few comments of mine (but most text you find below 
is from the tutorial).

On default in Rust types are immutable. If you want the mutable 
type you need to annotate it with "mut" in some way.

Rust designers seems to love really short keywords, this is in my 
opinion a bit silly. On the other hand in D you have keywords 
like "immutable" that are rather long to type. So I prefer a mid 
way between those two.

Rust has type classes from Haskell (with some simplifications for 
higher kinds), uniqueness typing, and typestates.

In Haskell typeclasses are very easy to use.

 From my limited study, the Rust implementation of uniqueness 
typing doesn't look hard to understand and use. It statically 
enforced, it doesn't require lot of annotations and I think its 
compiler implementation is not too much hard, because it's a pure 
type system test. Maybe D designers should take a look, maybe for 
D3.

Macros are planned, but I think they are not fully implemented.

I think in Go the function stack is segmented and growable as in 
Go. This saves RAM if you need a small stack, and avoids stack 
overflows where lot of stack is needed.

-------------------------

Instead of the 3 char types of D, Rust has 1 char type:

char  A character is a 32-bit Unicode code point.

-------------------------

And only one string type:

str  String type. A string contains a UTF-8 encoded sequence of 
characters.

For algorithms that do really need to index by character, there's 
the option to convert your string to a character vector (using 
str::chars).

-------------------------

Tuples are rightly built-in. Tuple singletons are not supported 
(empty tuples are kind of supported with ()):


(T1, T2)  Tuple type. Any arity above 1 is supported.

-------------------------

Despite Walter said that having more than a type of pointer is 
bad, both Ada and Rust have several pointer types. Rust has three 
of them (plus their mutable variants).


Rust supports several types of pointers. The simplest is the 
unsafe pointer, written *T, which is a completely unchecked 
pointer type only used in unsafe code (and thus, in typical Rust 
code, very rarely). The safe pointer types are @T for shared, 
reference-counted boxes, and ~T, for uniquely-owned pointers.

All pointer types can be dereferenced with the * unary operator.

Shared boxes never cross task boundaries.

-------------------------

This seems a bit overkill to me:

It's also possible to avoid any type ambiguity by writing integer 
literals with a suffix. The suffixes i and u are for the types 
int and uint, respectively: the literal -3i has type int, while 
127u has type uint. For the fixed-size integer types, just suffix 
the literal with the type name: 255u8, 50i64, etc.

-------------------------

This is very strict, maybe too much strict:

No implicit conversion between integer types happens. If you are 
adding one to a variable of type uint, saying += 1u8 will give 
you a type error.

-------------------------

Even more than Go:

++ and -- are missing


And fixes a C problem:

the logical bitwise operators have higher precedence. In C, x & 2 
 > 0 comes out as x & (2 > 0), in Rust, it means (x & 2) > 0, 
which is more likely to be what you expect (unless you are a C 
veteran).

-------------------------

Enums are datatypes that have several different representations. 
For example, the type shown earlier:

enum shape {
     circle(point, float),
     rectangle(point, point)
}

A value of this type is either a circle, in which case it 
contains a point record and a float, or a rectangle, in which 
case it contains two point records. The run-time representation 
of such a value includes an identifier of the actual form that it 
holds, much like the 'tagged union' pattern in C, but with better 
ergonomics.

The above declaration will define a type shape that can be used 
to refer to such shapes, and two functions, circle and rectangle, 
which can be used to construct values of the type (taking 
arguments of the specified types). So circle({x: 0f, y: 0f}, 10f) 
is the way to create a new circle.

Enum variants do not have to have parameters. This, for example, 
is equivalent to a C enum:

enum direction {
     north,
     east,
     south,
     west
}

-------------------------

This is probably quite handy:

A powerful application of pattern matching is destructuring, 
where you use the matching to get at the contents of data types. 
Remember that (float, float) is a tuple of two floats:

fn angle(vec: (float, float)) -> float {
     alt vec {
       (0f, y) if y < 0f { 1.5 * float::consts::pi }
       (0f, y) { 0.5 * float::consts::pi }
       (x, y) { float::atan(y / x) }
     }
}

- - - - - - - -

Records can be destructured in alt patterns. The basic syntax is 
{fieldname: pattern, ...}, but the pattern for a field can be 
omitted as a shorthand for simply binding the variable with the 
same name as the field.

alt mypoint {
     {x: 0f, y: y_name} { /* Provide sub-patterns for fields */ }
     {x, y}             { /* Simply bind the fields */ }
}

The field names of a record do not have to appear in a pattern in 
the same order they appear in the type. When you are not 
interested in all the fields of a record, a record pattern may 
end with , _ (as in {field1, _}) to indicate that you're ignoring 
all other fields.

- - - - - - - -

For enum types with multiple variants, destructuring is the only 
way to get at their contents. All variant constructors can be 
used as patterns, as in this definition of area:

fn area(sh: shape) -> float {
     alt sh {
         circle(_, size) { float::consts::pi * size * size }
         rectangle({x, y}, {x: x2, y: y2}) { (x2 - x) * (y2 - y) }
     }
}

-------------------------

This is quite desirable in D too:

To a limited extent, it is possible to use destructuring patterns 
when declaring a variable with let. For example, you can say this 
to extract the fields from a tuple:

let (a, b) = get_tuple_of_two_ints();

-------------------------

Stack-allocated closures:

There are several forms of closure, each with its own role. The 
most common, called a stack closure, has type fn& and can 
directly access local variables in the enclosing scope.

let mut max = 0;
[1, 2, 3].map(|x| if x > max { max = x });

Stack closures are very efficient because their environment is 
allocated on the call stack and refers by pointer to captured 
locals. To ensure that stack closures never outlive the local 
variables to which they refer, they can only be used in argument 
position and cannot be stored in structures nor returned from 
functions. Despite the limitations stack closures are used 
pervasively in Rust code.

-------------------------

Unique closures:

Unique closures, written fn~ in analogy to the ~ pointer type 
(see next section), hold on to things that can safely be sent 
between processes. They copy the values they close over, much 
like boxed closures, but they also 'own' them—meaning no other 
code can access them. Unique closures are used in concurrent 
code, particularly for spawning tasks.


There are also heap-allocated closures (so there are 3 kinds of 
closures).

- - - - - - - -

In contrast to shared boxes, unique boxes are not reference 
counted. Instead, it is statically guaranteed that only a single 
owner of the box exists at any time.

let x = ~10;
let y <- x;

This is where the 'move' (<-) operator comes in. It is similar to 
=, but it de-initializes its source. Thus, the unique box can 
move from x to y, without violating the constraint that it only 
has a single owner (if you used assignment instead of the move 
operator, the box would, in principle, be copied).

Unique boxes, when they do not contain any shared boxes, can be 
sent to other tasks. The sending task will give up ownership of 
the box, and won't be able to access it afterwards. The receiving 
task will become the sole owner of the box.

-------------------------

In D you control this adding "private" before names, but I think 
a centralized control point at the top of the module is safer and 
cleaner:

By default, a module exports everything that it defines. This can 
be restricted with export directives at the top of the module or 
file.

mod enc {
     export encrypt, decrypt;
     const super_secret_number: int = 10;
     fn encrypt(n: int) -> int { n + super_secret_number }
     fn decrypt(n: int) -> int { n - super_secret_number }
}

-------------------------

This is needed by the uniqueness typing:

Evaluating a swap expression neither changes reference counts nor 
deeply copies any unique structure pointed to by the moved rval. 
Instead, the swap expression represents an indivisible exchange 
of ownership between the right-hand-side and the left-hand-side 
of the expression. No allocation or destruction is entailed.

An example of three different swap expressions:

x <-> a;
x[i] <-> a[i];
y.z <-> b.c;

-------------------------

For some info on the typestate system, from the Rust manual:

http://dl.rust-lang.org/doc/rust.html#typestate-system

This description is simpler than I have thought. It seems 
possible to create an experimental D compiler with just a similar 
typestate system, it looks like a purely additive change (but 
maybe it's not a small change). It seems to not even require new 
syntax, beside an assert-like check() that can't be disable and 
that uses a pure expression/predicate.

Bye,
bearophile