[ComputerGuru]

Yes, anything implemented for &str is automatically implemented for String... except some API are stupidly implemented for &string instead. And you can't pattern match strings properly (think some `for in`) without first explicitly converting to &str.

Dereferencing a string does not return a raw pointer, that was exaggeration on my behalf. But a string is a container, so *string returns.... &str? But string.deref() returns str?

Don't get me wrong, I'm fully invested in the language [0], [1], [2], but it's got a lot of warts that could have been avoided by thinking bigger picture. So many APIs are restricted by thinking easy instead of big pre-1.0. Like str being hardcoded into APIs that should have been generic (FromStr vs From<&str>, .parse() vs .into()), shipping 1.0 without async/await, and the whole mess with strings.

0: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is...

1: https://github.com/rust-lang/rfcs/issues?utf8=%E2%9C%93&q=is...

2: https://crates.io/search?q=neosmart

[masklinn]

> But a string is a container

In the same way unique_ptr is a container.

> so string.deref() returns.... &str?

Yes? &str::deref() also returns &str, Vec::deref() returns &[], Box<T>::deref() returns &T.

That's literally how Deref is defined, Deref<Target=T>::deref() returns &T.

*String returns str.

> (FromStr vs From<&str>, .parse() vs .into())

These are not equivalent. From/Into are non-failing conversions, FromStr can fail.

What you're looking for is TryFrom/TryInto which are still not done 2 years into the RFC: https://github.com/sfackler/rfcs/blob/try-from/text/0000-try...

[ComputerGuru]

> * String returns str.

Typed that out too fast, yes, that's my problem. * String is one thing but String.deref() is another. But * is the dereference operator. Operator overloading ftw ;)

> What you're looking for is TryFrom/TryInto which are still not done 2 years into the RFC: https://github.com/sfackler/rfcs/blob/try-from/text/0000-try....

Sorry, yes, I actually opened an issue with my suggestions regarding that one with particular focus on the fallible vs infallible nature: https://github.com/rust-lang/rfcs/issues/2143

[masklinn]

> Typed that out too fast, yes, that's my problem. * String is one thing but String.deref() is another. But * is the dereference operator.

They're the same thing, Deref::deref() is just the operation which underlies the dereferencing operator.

Either way I don't see what's problematic about a string buffer deref'ing to a string.

[steveklabnik]

> except some API are stupidly implemented for &string instead.

Which ones are those? I can't think of any off the top of my head, though brains are fallible!

[ComputerGuru]

Hi Steve! Sorry, I didn't mean to imply in the core API. I don't think (though I too could be wrong) that &string is used anywhere that AsRef<OsStr> isn't also available.