Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd generic conversion traits #23538
Conversation
rust-highfive
assigned
alexcrichton
Mar 20, 2015
This comment has been minimized.
This comment has been minimized.
|
PRELIMINARY PR: Do not merge until the RFC is approved. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Per IRC: @alexcrichton is very uncomfortable with these living in |
This comment has been minimized.
This comment has been minimized.
|
cc @reem |
This comment has been minimized.
This comment has been minimized.
|
Per IRC: @reem points out that the same coherence problems make it much more difficult to define "implicit conversions" via generics targetting user-land types: you cannot implement Introducing an ad hoc conversion trait, on the other hand, makes it possible to do this in userland. |
aturon
force-pushed the
aturon:conversion
branch
from
9fcd79f
to
844c115
Mar 20, 2015
This comment has been minimized.
This comment has been minimized.
|
Updated: I've now moved the traits into |
aturon
force-pushed the
aturon:conversion
branch
6 times, most recently
from
c8671be
to
3c62067
Mar 20, 2015
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
I believe this is now ready to go, once the RFC itself has been merged. |
alexcrichton
reviewed
Mar 20, 2015
| @@ -14,6 +14,7 @@ | |||
|
|
|||
| use core::clone::Clone; | |||
| use core::cmp::{Eq, Ord, Ordering, PartialEq, PartialOrd}; | |||
| use core::convert::As; | |||
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
Could these traits also go into the libcore prelude? I think files like this can have use core::prelude::* at the top as well (slowly been migrating over time).
alexcrichton
reviewed
Mar 20, 2015
| /// A cheap, reference-to-reference conversion. | ||
| pub trait As<T: ?Sized> { | ||
| /// Perform the conversion. | ||
| fn convert_as(&self) -> &T; |
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
I do quite like your suggestions on the RFC of as_ref, as_mut, to, and into. The only one that's "wrong" is as_ref (e.g. it should be called as) but it seems worth it!
This comment has been minimized.
This comment has been minimized.
Gankro
Mar 20, 2015
Contributor
Wouldn't as_ref and as_mut conflict with several adhoc methods (thinking of RawPtr and Option off the top of my head)?
This comment has been minimized.
This comment has been minimized.
aturon
Mar 20, 2015
Author
Member
They would overlap, but inherent impls trump trait ones. (Still, the overlap is one reason we might not want to choose these names, or might consider renaming the others...)
alexcrichton
reviewed
Mar 20, 2015
| fn convert_as(&self) -> &[T] { | ||
| self.as_slice() | ||
| } | ||
| } |
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
I thought we've been pretty hesitant about this in the past? Slices from Option and Result I thought would continue to be unstable functionality.
This comment has been minimized.
This comment has been minimized.
aturon
Mar 20, 2015
Author
Member
I'm willing to mark this unstable, but personally I have no objection to this functionality, especially in the context of generic conversions.
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
My fear in marking these unstable is that there's no warning on usage of an unstable impl, only on an unstable trait, and it's not clear that we'll get it fixed for 1.0.
alexcrichton
reviewed
Mar 20, 2015
|
|
||
| /// Convert from `Option<T>` to `&[T]` (without copying) | ||
| #[inline] | ||
| #[stable(feature = "rust1", since = "1.0.0")] |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
alexcrichton
reviewed
Mar 20, 2015
| @@ -8,6 +8,7 @@ | |||
| // option. This file may not be copied, modified, or distributed | |||
| // except according to those terms. | |||
|
|
|||
| use std::convert::From; | |||
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
aturon
Mar 20, 2015
Author
Member
It's in the prelude, yes; I probably added a few redundant imports mechanically.
This comment has been minimized.
This comment has been minimized.
alexcrichton
reviewed
Mar 20, 2015
| } | ||
|
|
||
| #[stable(feature = "rust1", since = "1.0.0")] | ||
| impl From<String> for OsString { |
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
I wonder if these would be better expressed as Into? For example functions may want to take T: Into<OsString>.
alexcrichton
reviewed
Mar 20, 2015
| @@ -999,16 +1036,58 @@ impl PathBuf { | |||
| } | |||
|
|
|||
| #[stable(feature = "rust1", since = "1.0.0")] | |||
| impl<P: AsPath> iter::FromIterator<P> for PathBuf { | |||
| impl<'a> From<&'a str> for PathBuf { | |||
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
Similarly to the OsString case, these may be better expressed via Into.
It's also a little sad that the same set of impls as From<T> for OsString needs to be listed here, but not necessarily the end of the world.
This comment has been minimized.
This comment has been minimized.
aturon
Mar 20, 2015
Author
Member
Yes, the inability to do blanket "transportation" of one conversion to another is a loss here.
Note that specialization may someday allow us to regain this via automatic reflexive and transitive blankets. It's not clear.
This comment has been minimized.
This comment has been minimized.
Gankro
reviewed
Mar 20, 2015
| None => { | ||
| if parse_name_directive(line, "pp-exact") { | ||
| testfile.file_name().map(|s| PathBuf::new(s)) | ||
| testfile.file_name().map(|s| PathBuf::from(s)) |
This comment has been minimized.
This comment has been minimized.
Gankro
reviewed
Mar 20, 2015
| let mut result = Vec::with_capacity(size + self.len()); | ||
| let mut first = true; | ||
| for v in self { | ||
| if first { first = false } else { result.push(sep.clone()) } | ||
| result.push_all(v.as_slice()) | ||
| result.push_all(v.convert_as()) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
aturon
Mar 20, 2015
Author
Member
Yeah, it's probably more clear to perform the conversion up-front and rebind the variable (perhaps with type annotation, even).
This comment has been minimized.
This comment has been minimized.
alexcrichton
Mar 20, 2015
Member
Note, though, that v.as_ref::<[_]>() would probably still be readable.
This comment has been minimized.
This comment has been minimized.
Gankro
Mar 20, 2015
Contributor
Alternatively if these traits were hooked into coercions you could just result.push_all(&v), which is less informative but somehow less cryptic than covert_as::<???>().
This comment has been minimized.
This comment has been minimized.
|
cc #23567 |
aturon
force-pushed the
aturon:conversion
branch
from
3c62067
to
dbd9480
Mar 23, 2015
aturon
changed the title
[WIP] Add generic conversion traits
Add generic conversion traits
Mar 23, 2015
This comment has been minimized.
This comment has been minimized.
|
Updated:
All in all, I feel much better with the form this PR is taking now. It feels cleaner, leaner, more consistent and more extensible. Thanks for the feedback making this possible! @alexcrichton: re-r? |
alexcrichton
reviewed
Mar 23, 2015
| @@ -67,8 +67,8 @@ pub fn current_dir() -> io::Result<PathBuf> { | |||
| /// println!("Successfully changed working directory to {}!", root.display()); | |||
| /// ``` | |||
| #[stable(feature = "env", since = "1.0.0")] | |||
| pub fn set_current_dir<P: AsPath + ?Sized>(p: &P) -> io::Result<()> { | |||
| os_imp::chdir(p.as_path()) | |||
| pub fn set_current_dir<P: AsRef<path::Path> + ?Sized>(p: &P) -> io::Result<()> { | |||
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
aturon
Mar 23, 2015
Author
Member
Ahha! It can now. I think when I first wrote it Path was still in the prelude :)
This comment has been minimized.
This comment has been minimized.
|
I, too, am quite happy with how this is turning out! r=me with the |
aturon
force-pushed the
aturon:conversion
branch
from
dbd9480
to
a686d27
Mar 23, 2015
This comment has been minimized.
This comment has been minimized.
|
pings addressed :) |
aturon
force-pushed the
aturon:conversion
branch
from
a686d27
to
8389253
Mar 23, 2015
This comment has been minimized.
This comment has been minimized.
aturon
force-pushed the
aturon:conversion
branch
from
8389253
to
97c8e43
Mar 23, 2015
This comment has been minimized.
This comment has been minimized.
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Mar 23, 2015
aturon
force-pushed the
aturon:conversion
branch
from
97c8e43
to
08ee682
Mar 23, 2015
This comment has been minimized.
This comment has been minimized.
|
Rolled into #23654 |
alexcrichton
closed this
Mar 24, 2015
This comment has been minimized.
This comment has been minimized.
|
|
aturon commentedMar 20, 2015
This commit:
Introduces
std::convert, providing an implementation ofRFC 529.
Deprecates the
AsPath,AsOsStr, andIntoBytestraits, allin favor of the corresponding generic conversion traits.
Consequently, various IO APIs now take
As<Path>rather thanAsPath, and so on. Since the types provided bystdimplement bothtraits, this should cause relatively little breakage.
Deprecates many
from_fooconstructors in favor offrom.Changes
PathBuf::newto take no argument (creating an empty buffer,as per convention). The previous behavior is now available as
PathBuf::from.De-stabilizes
IntoCow. It's not clear whether we need this separate trait.Closes #14433
Closes #22751
[breaking-change]
r? @alexcrichton
cc @Gankro @erickt @cmr