You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One is in impl String in libcollections/string.rs and has the signature fn from_str(string: &str) -> String.
The other is in impl FromStr for String in libstd/from_str.rs and has the signature fn from_str(s: &str) -> Option<String>. In fact, FromStr::from_str() actually calls String::from_str().
This situation probably came about because struct String exists in libcollections, which you could conceivably have without libstd in a freestanding environment, and the FromStr trait lives in libstd.
Conceivably, FromStr could be moved to a different crate, or a dependency on libstd could be introduced to libcollections.
The text was updated successfully, but these errors were encountered:
It isn't a duplication or conflict, String::from_str is a natural constructor function for String and the other is a result of implementing that trait. They won't be confused in practice.
One is in
impl String
in libcollections/string.rs and has the signaturefn from_str(string: &str) -> String
.The other is in
impl FromStr for String
in libstd/from_str.rs and has the signaturefn from_str(s: &str) -> Option<String>
. In fact, FromStr::from_str() actually calls String::from_str().This situation probably came about because
struct String
exists in libcollections, which you could conceivably have without libstd in a freestanding environment, and the FromStr trait lives in libstd.Conceivably, FromStr could be moved to a different crate, or a dependency on libstd could be introduced to libcollections.
The text was updated successfully, but these errors were encountered: