On Tue, Dec 20, 2011 at 10:16:47AM -0800, Niko Matsakis wrote:
> Hi,
> 
> In preparation for the 0.1 release, Brian and I were thinking it
> might be nice to try to address small, annoying problems that come
> up in everyday Rust programming.  Of course, a lot of these are
> already the result of compromises over contentious issues (e.g.,
> trailing dot for nullary tag in a pattern), but I'd still like to
> know what the set of annoying things are; some of them may be easier
> to resolve now.  Can you please e-mail me your favorite pet
> peeve(s).  Thanks.

1. Type suffixes on integer literals. I trip _constantly_ over the fact that I
must say 'vec::slice(..., 0u, ...)' instead of 'vec::slice(..., 0, ...)'. I wish
these were automatically cast to the appropriate type if within range. This is
the biggest single drag to writing Rust code day-to-day for me.

2. The dot after the nullary tag. In general I want to write a nullary tag a LOT
more often than I want to write a wildcard binder, so I feel like this is the
wrong way for this choice to go, but I'll understand if this is a decided issue
already.

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.

4. I wish a lot more of the standard library was object-oriented. I realize this
is somewhat of a slippery slope, but writing 'vec::len(thing)' is less nice (to
me) than thing.len(). I think that things in the standard library that are
object-like (vec, str, ...) should be objects.

5. I do not like the mk_foo()/obj foo {} idiom; it forces code another tabstop
to the right.

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?
 
> Niko
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-- elly

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to