Make String/str, Vec/[] conversions more ergonomic

[brson]

There's a lot of code right now that does things like frob(&"foo".to_string()).as_slice(), using method calls to do both 'free' and non-free coercions. While the underlying string semantics may be good, it's not so usable as one might like.

We need to figure out a way to minimize the burden of these, and other, coercion methods without compromising predictability.

Nominating.

[nikomatsakis]

cc me

[brson]

Another consideration regarding coercions: There are a number of constructors in std that want to take something like fn open<T: SomethingLikeAPath>(path: T). We have in the past decided not to do this and force callers to do explicit conversions, but people don't like it. These are cropping up more and more. @alexcrichton knows specific examples.

[steveklabnik]

In Ruby, we have standard methods that convert things. If the call-ee wants a string, it will call to_s on the argument, so you can know that it's a string for the rest of the body.

I would expect this would be against the 'zero cost' mentality, though.

[brson]

1.0, P-high.

[nixpulvis]

I know rust doesn't really have a notion of a constructor function, but could this be a good case for the addition of a cast constructor, allowing for implicit casts. Totally a design decision, just wondering. This is defiantly one of my least favorite things about programming in rust at the moment.

[aturon]

Note, the slice notation RFC would help here.

[japaric]

String/Vec<T> implement Deref<str>/Deref<[T]> , and we now have slicing [a..b] sugar. Can this be considered solved?

[alexcrichton]

I would think so! Nominating to be closed at the next triage meeting.

[pnkfelix]

team believes the issues here either are or will be handled by un-feature gating slice notation and/or other items in the RFC pipeline (such as deref coercions). Closing.