On Tue, Dec 20, 2011 at 2:55 PM, Elly Jones <[email protected]> wrote:
>
> 3. The use of alt in situations which would be handled with a guard clause in
> C.
> For example, in C, I might write:
>
> if (!foo->is_bar()) { return OOPS; }
> bar = foo->get_bar();
>
> Whereas in Rust, I have to write:
>
> let mybar = alt foo {
> bar(_v) { _v }
> _ { fail "OOPS"; }
> }
>
> This is okay, but it's an operation I do a _lot_, so I'd sort of like a
> lighter
> syntax for it, like:
>
> let bar(mybar) = foo else { fail "OOPS"; }
>
> With the restriction that the else {} block may not continue execution, I
> don't
> think this is terribly semantically incoherent.
It could also just supply a default:
let bar(mybar) = foo else { bar(5) }
Then fail would be a special case that would be valid too since
control doesn't leave the block.
Not sure I like this though. Wouldn't it be quite rare for failure to
be the right option when a tag doesn't have the right arm? Wouldn't
you rather chain the values together using the functions in the option
module to propagate the "none" further up?
> 6. Having to export all the members of a tag you're exporting seems bizarre;
> when would you ever want the tag but not its members?
The majority of the time, I'd think? Wouldn't you usually want to keep
the internals of data types opaque to other modules so that you're
forced to call the functions in the module to operate on it? Would be
nice to have a shorthand for just exporting all the members though, a
la Haskell.
--
Sebastian Sylvan
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
