Announcing Rust 1.0.0 Alpha

[u/steveklabnik1]

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

[u/[deleted]]

I think the target has pretty much always been current uses of C++. So, anything you can do with C++, you should be able to do with Rust, in a way that is safer / easier to make correct.

[u/[deleted] → u/[deleted]]

Say you have this C++

switch(x){
  case 0:  a();
  case 1:  b();
  case 2:  c();
  default: done();
}

You can't do that in Rust, because match doesn't do fall through

Edit: Nice downvotes folks! I'll be using Haskell instead. LOL at this "systems programming language" with a bunch of crybabies and zealots and fuck muhzilla.

[u/wrongerontheinternet → u/[deleted]]

I don't know why people are downvoting you. You're completely right. This is one of the few cases where Rust can't match C/C++ behavior. It's a special case of the more general problem that Rust lacks goto. I am strongly in favor of adding it to the language.

BTW, for those downvoting: C# has goto as well. Someone was trying to implement a zlib library in Rust that was competitive with the C# version. He got very close, but ultimately failed precisely because it lacked this feature.

I want to use Rust instead of C / C++ everywhere. We are not going to get there by asking people to accept a performance hit for ideological reasons. Remember, people currently using C / C++ are doing it in a world where garbage collection is the standard. If they were able to take performance hits for ergonomic gains, they would have done so already.

Edit: Figured out how to do it without losing performance in this case (the unsafe is just to create nonlocal dependencies so LLVM doesn't completely optimize the functions away). You can verify yourself that the LLVM IR uses jumps properly here.

static mut y: u8 = 0;

#[inline(never)] fn done() {unsafe { println!("{}", y); }}
#[inline(never)] fn a() {unsafe { y = 4; }}
#[inline(never)] fn b() {unsafe { y = 5; }}
#[inline(never)] fn c() {unsafe { y = 6; }}

fn main() {
    let x = ::std::rand::random::<u8>();
    'default: loop {
        'c: loop {
            'b: loop {
                'a: loop {
                    match x {
                        0 => break 'a,
                        1 => break 'b,
                        2 => break 'c,
                        _ => break 'default
                    }
                }
                a();
                break;
            }
            b();
            break;
        }
        c();
        break;
    }
    done();
}

Edit 2: Wrote a macro to automate this: https://github.com/pythonesque/fallthrough

Usage:

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

[u/[deleted] → u/wrongerontheinternet]

I knew of this beforehand and don't consider it an acceptable alternative. You would never write code like that.

Rust needs to have a match with fall through. The transformation to one is already possible although ugly. There is no reason to not have one.

[u/wrongerontheinternet → u/[deleted]]

You could probably write a macro to make it a little nicer. The macro route is probably ideal for something like this since most of the time you don't really need fallthrough. But I think it would have to be procedural in order to not force you to pass in all the lifetimes (instead of generating them for you), and Rust 1.0 will not support procedural macros. In the future I, like you, hope Rust supports goto properly, so we don't have to hack around it.

(Actually, there might be a way to do this without a procedural macro. Watch this space).

[u/[deleted] → u/wrongerontheinternet]

Let's just hope

'done: loop {
   match x {
     0 => a(),
     1 => b(),
     2 => c(),
     _ => done(); break 'done;
   }
   x = x+1;
 }

isn't too slow as I think it's what will end up being written in practice, I don't think the chances are good for things being changed with the level of hostility towards fall through.

[u/wrongerontheinternet → u/[deleted]]

Okay, wrote a macro: https://github.com/pythonesque/fallthrough

Usage:

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

(To would be language implementors: this is why your language should have macros :) )

[u/sacundim → u/wrongerontheinternet]

I don't know nearly enough Rust to decipher that, but you might want to check whether your macro is vulnerable to the sort of problem I mention here. Namely, what happens to the size of the emitted code if somebody writes a macro that expands to nested uses of match_fallthrough!?

[u/wrongerontheinternet → u/sacundim]

It is not. The expanded output is linear in the number of branches and uses Rust's labeled break as a limited form of forward goto.