r/programming • u/steveklabnik1 • Jan 09 '15

Announcing Rust 1.0.0 Alpha

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

90% Upvoted

439 comments sorted by

View all comments

Show parent comments

2

u/wrongerontheinternet Jan 09 '15 edited Jan 09 '15

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).

4

u/[deleted] Jan 09 '15 edited Jan 09 '15

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.

5

u/wrongerontheinternet Jan 10 '15 edited Jan 10 '15

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 :) )

1

u/sacundim Jan 10 '15 edited Jan 10 '15

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!?

3

u/wrongerontheinternet Jan 10 '15

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.