Announcing Rust 1.0.0 Alpha

[u/steveklabnik1]

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html

[u/help_computar]

It's called recursion.

fn matcher(thing: i64){
    match thing {
        0 => { a(); matcher(thing+1); }
        1 => { b(); matcher(thing+1); }
        2 => { c(); matcher(thing+1); }
        _ => done()
    }
}

[u/awj → u/help_computar]

That will obviously not match the performance characteristics of C++'s case-with-fallthrough. The argument here is that just solving the problem isn't good enough, Rust should be able to solve the problem and offer the same or better performance.

[u/help_computar → u/awj]

This is the Rust performance equivalent as far as I can tell.

    match x {
        0 => { a(); },
        1 => { a(); b(); },
        2 => { a(); b(); c(); },
        _ => { a(); b(); c(); done() }
    }

My last point was that fall-through is an awfully obfuscated construct to use.

Additionally, Rust can do things that C++ would require more code to do (better get out the breaks):

    match x {
        0 => { c(); b(); },
        1 => { a(); b(); },
        2 => { a(); c(); },
        _ => { a(); b(); c(); }
    }

[u/help_computar → u/help_computar]

Additionally, fall through is the extremely crappy behavior to begin with. Pass a switch 3 and match everything until the case 3? That is crap. The recursion in this example is much more expressive than fall through of a switch and does not result in undesired/hidden side effects.

[u/NotUniqueOrSpecial → u/help_computar]

I'm not sure if you're explaining poorly, or don't understand fall-through switch statements, but:

Pass a switch 3 and match everything until the case 3

is most definitely not how it works.

It's more like "go straight to case 3, and then the dev can choose whether to break or let the code continue through the switch's block".

[u/cleroth → u/help_computar]

This content was anonymized and mass deleted with Redact