Kimundi

mod foobar {
    pub trait Foo {
        static fn foo(int)    -> Self;
        fn foo_add(&self,int) -> Self;
    }

    pub struct Bar {
        value: int
    }

Kimundi

Window refresh callback triggered.
Window focus gained.
Key Escape: Pressed
rust: task failed at 'Assertion str::len(s) <= pad failed', /home/marvin/dev/rust/fork/rust/src/libcore/char.rs:203
callbacks: /home/marvin/dev/rust/fork/rust/src/rt/rust_upcall.cpp:92: void upcall_call_shim_on_rust_stack(void*, void*): Assertion `false && "Rust task failed after reentering the Rust stack"' failed.
Aborted

Kimundi

// So, you have this trait:

trait CompiledRegularExpression {
    fn full_match(&self, input: &str) -> bool;
    fn partial_match(&self, input: &str) -> bool;
    fn shortest_match(&self, input: &str) -> Option<(uint, uint)>;
    fn longest_match(&self, input: &str) -> Option<(uint, uint)>;
    fn shortest_match_slice<'a>(&self, input: &'a str) -> Option<&'a str>;
    fn longest_match_slice<'a>(&self, input: &'a str) ->Option<&'a str>;
    // ...

Kimundi

enum State {
  A, B, C
}

let mut state = A;

loop {
  state = match state {
    A => { ... }
    B => { ... }

Kimundi

Full syntax:

re!(re_str
    [, engine 
        [(force|error on|warn on) runtime (compile|parse)]*
        [, engine_flags]
    ]
) -> CompiledRe

re!()'s contract: Accept static and non-static strings, any engine implementing either ReAstCompiler or ReStrCompiler, with compiletime guarantees degrading depending on inputs:

Kimundi

Syntax extension

The re!() syntax extension accepts an string literal and optional flags, and returns an type T implementing CompiledRegularExpression:

re!("re_string_literal"[, options, ...]) -> T 

The parse_re!() syntax extension just accepts an string literal and returns an type ReAst representing the regular expressions AST.

parse_re!("re_string_literal") -> ReAst

Kimundi

Custom Smartpointer Sugar (v2)

Reading the Meeting notes at https://github.com/mozilla/rust/wiki/Meeting-2013-06-07, it seems that there is general agreement with the idea to move @T and @mut T from build-in constructs to library types, provided it's possible to keep the same semantic with the help of lang items and traits.

This proposal is about the '@ vs Gc<>' issue mentioned at the end of those notes, to which I say:

"Why not both?"

To elaborate, I propose that the current 'hardcoded-to-gc-@'-ptr syntax disappears, and that the @-sigil gets re-purposed as special sugar for (custom) library types:

Kimundi

Proposal for an additional use case of the in keyword besides for-loops:

Right now you can destructure with a pattern everywhere where you can introduce new local variables: let, match and in function signatures.

However, sometimes you are in the need of destructuring some values, but don't want to introduce a new variable for them, instead intending to store their result in some mutable bindings that are already in scope. To achieve that right now, you have to create a temporary local variable and move its content to the other one. Example:

fn foo() -> (int, int, int);

let mut x = 42;

let mut z = 0;

Kimundi

Crates and the module system

Rust's module system is very powerful, but because of that also somewhat complex. Nevertheless, this section will try to explain every important aspect of it.

Crates

In order to speak about the module system, we first need to define the medium it exists in:

Let's say you've written a program or a library, compiled it, and got the resulting binary.

Kimundi

macro_rules! matches (
    ($e:expr, $($p:pat)|+) => (
        match &$e {
            $(&$p)|+ => true,
            _ => false
        }
    );
    ($e:expr, $($p:pat)|+ if $g:expr) => (
        match &$e {
            $(&$p)|+ if $g=> true,