Re:Rust's 2017 Roadmap
by rspeer on Monday February 06, 2017 @07:58PM
(#13585983)
I mean, if I have a method foo() that returns a String, as many methods do, why can't I check if foo() == "bar"? Why do I have to check foo() == "bar".to_string()?
[ Parent
| on HN ]
Re:Rust's 2017 Roadmap
by steveklabnik on Monday February 06, 2017 @08:13PM
(#13586056)
Works just fine here: https://play.rust-lang.org/?gist=5a3228a1d42d81690458337eb77...
Maybe you were running into something else?
String == &str works. Maybe you were encountering some other problem.
Oh, I guess the case of this I encountered most recently was actually Option<String> == Option<&str>.
I get why that's different, but it would be great if the type system could figure that out, so that the literal Some("foo") could be an Option<String> if necessary. Maybe I'm still being spoiled by Haskell's OverloadedStrings.
Nitpick: if you have a String and a &str, you want to convert the first to the second, not the other way around. Strings are owned, so &str to String does an allocation and copy of the bytes, while String to &str is a trivial operation that just throws away the capacity field.
But yeah, it would be nice if Rust had better ergonomics regarding coercing the insides of wrapper types. Though I'm not sure how exactly that would work.
You can do:
foo() -> Option<String>
foo().as_ref() == Some("str")
Re:Rust's 2017 Roadmap
by tatterdemalion on Tuesday February 07, 2017 @05:38AM
(#13588468)
> Oh, I guess the case of this I encountered most recently was actually Option<String> == Option<&str>.
There are pretty rough type inference issues preventing this impl from existing. Too many people are doing `opt == None` & the compiler would no longer be able to infer the type of None. (You should not be one of them, just call `is_none()` instead)
I'd like to see this impl some day but its not clear how to make it happen.