4 ms·

When you say "terrible", are you complaining about having to write `.as_slice()` and `.to_string()` all the time? For context for others who may not have a lot

• kasey_junk 12y ago
  That is part of the problem. The bigger part of the problem is comparing String's with constants. It simply doesn't work easily. Also, start trying to do pattern matching on Vec<String> vs Vec<str> (and the wide variety of static, ref, etc versions there in) and you end up spending a lot of effort to do what is very basic in most languages that support generic pattern matching. Try a simple use case, parse a command line argument array via pattern matching in a Rust program.
  • dbaupp 12y ago
    Comparing a constant: string.as_slice() == "foo" "Parsing" command line args (it's not as slick as it could be, but it's not entirely horrible... for me as an experienced Rust user anyway): match std::os::args().as_slice() { [] => println!("need more arguments"), [ref x, ..] if x.as_slice() == "-h" => print_help(), [ref a, ref b] if a.as_slice() == "-f" => write_to_file(b.as_slice()) args @ _ => println!("unrecognised arguments: {}", args) } Of course, using a proper parser like getopts or docopt.rs would be better: - http://doc.rust-lang.org/master/getopts/ http://doc.rust-lang.org/master/getopts/ - https://github.com/BurntSushi/docopt.rs https://github.com/BurntSushi/docopt.rs I think it gets smoother with practice (as in, with practice you're able to know intuitively when you need .as_slice and when a `ref` is required etc.), but yes, improving the ergonomics will be nice. Dynamically sized types will allow for String to be treated implicitly as a &str in many cases, so, e.g., my_string.trim() will work (it currently requires `my_string.as_slice().trim()`). And there is some loose talk about overloading pattern matching via the same mechanism, which would allow proper pattern matching on String with literals `"..."`. > support generic pattern matching. There's some subtlety here, e.g. Haskell doesn't support pattern matching on Data.Vector.Vector or Data.Text.Text (which are some of the closest equivalents to &[T], Vec<T> and String).
    • kasey_junk 12y ago
      A) I understand how to make Rust do what I want with strings. B) Even with your examples, I think you've glossed over some of the even trivial use cases for dealing with Vec<String> vs Vec<~str> (or whatever the current nomenclature is). C) Even with your great comments you've pointed out that String manipulation in Rust is not "natural". Which is something that is a very high priority for me. That said, easy string manipulation is a high priority feature for me. Non-private data access is a high priority feature for the original commenter. I worry that too many of us have expectations for Rust that are unlikely to be fulfilled. That's not to say that the Rust team has set too high of barriers, only that we have elevated them to something they aren't. I'm less concerned with what the Rust team is delivering (which so far has been great) than with what people seem to be expecting (which is nothing less than a C++ replacement in all contexts).
      • kzrdude 12y ago
        The problem is that the string story is on two sides of a barrier erected in Rust very much by intention: To make memory allocation explicit, and to enable allocation-free operations as far as possible This is why Rust will have you juggle String (a string with allocation) and &str (a "string slice"; a view into an allocation elsewhere) all the time.
    • masklinn 12y ago
      Erlang does support pattern matching on binaries though, that that's really nice when splitting out and converting bits and bobs from binary data.