Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for RFC 2306, "Add core::convert::identity" #53500

Closed
2 tasks done
Centril opened this issue Aug 19, 2018 · 8 comments · Fixed by #57322
Closed
2 tasks done

Tracking issue for RFC 2306, "Add core::convert::identity" #53500

Centril opened this issue Aug 19, 2018 · 8 comments · Fixed by #57322
Assignees
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-RFC-implemented Blocker: Approved by a merged RFC and implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Aug 19, 2018

This is a tracking issue for the RFC "Add fn identity<T>(x: T) -> T { x } to core::convert" (rust-lang/rfcs#2306).

Steps:

Unresolved questions:

None.

@Centril Centril added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Aug 19, 2018
@Centril Centril self-assigned this Aug 19, 2018
Centril added a commit to Centril/rust that referenced this issue Aug 20, 2018
bors added a commit that referenced this issue Aug 20, 2018
Add the identity function as core::convert::identity

## New notes

This implements rust-lang/rfcs#2306 (see #53500).

## Old notes (ignore this in new reviews)

Adds the identity function `fn id<T>(x: T) -> T { x }` to core::convert and the prelude.
Some motivations for why this is useful are explained in the doc tests.
Another is that using the identity function instead of `{ x }` or `|x| x` makes it clear that you intended to use an identity conversion on purpose.

The reasoning:
+ behind adding this to `convert` and not `mem` is that this is an identity *conversion*.
+ for adding this to the prelude is that it should be easy enough to use that the ease of writing your own identity function or using a closure `|x| x` doesn't overtake that.

I've separated this out into two feature gates so that the addition to the prelude can be considered and stabilized separately.

cc @bluss
@Centril Centril added the B-RFC-implemented Blocker: Approved by a merged RFC and implemented. label Aug 20, 2018
@Centril Centril added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Sep 18, 2018
@shepmaster
Copy link
Member

The documentation suggests:

#![feature(convert_id)]
use std::convert::identity;

let iter = vec![Some(1), None, Some(3)].into_iter();
let filtered = iter.filter_map(identity).collect::<Vec<_>>();
assert_eq!(vec![1, 3], filtered);

I'd argue this is actively non-idiomatic Rust. It is better to use flatten

let iter = vec![Some(1), None, Some(3)].into_iter();
let filtered = iter.flatten().collect::<Vec<_>>();
assert_eq!(vec![1, 3], filtered);

I'm bringing this up here because if we can't have good examples, perhaps the feature doesn't carry it's own weight.

@shepmaster
Copy link
Member

The documentation suggests using identity to "do nothing among other interesting functions" and "that changes nothing in a conditional" (which are really the same example). I think this is very weak motivation because it cannot be used with a function of different arity:

#![feature(convert_id)]
use std::convert::identity;

fn manipulation(x: u32, y: u32) -> u32 {
    x + y
}

fn main() {
    let do_stuff = if true { manipulation } else { identity };
    let _results = do_stuff(1, 2);
}
error[E0308]: if and else have incompatible types
 --> src/main.rs:9:20
  |
9 |     let do_stuff = if true { manipulation } else { identity };
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ incorrect number of function parameters
  |
  = note: expected type `fn(u32, u32) -> u32 {manipulation}`
             found type `fn(_) -> _ {std::convert::identity::<_>}`

@Centril
Copy link
Contributor Author

Centril commented Sep 26, 2018

@shepmaster

So .flatten() was added to libcore as a direct consequence of discussing identity.

However, I think that:

let filtered = iter.filter_map(identity).collect::<Vec<_>>();

is more clear with respect to intent.

To know that .flatten() is equivalent to .filter_map(identity) one has to remember the behavior of Option<T> as IntoIterator so I would write the latter rather than the former. Note however that .flatten() is Iterator specific and may not exist for your random type. For example, there is no prop_flatten in Strategy. In such a case .flatten() can't be idiomatic because it does not exist.

I think this is very weak motivation because it cannot be used with a function of different arity:

Given that Rust is a typed language I am unsure as to why one would expect this to work with functions of different arity. This would be the same as expecting impl Fn(A) -> A to also support impl Fn(A, A) -> A. However, if you partially apply manipulation you can use identityand manipulation in a list of boxed closures.

@Centril
Copy link
Contributor Author

Centril commented Dec 13, 2018

@SimonSapin How do you feel about stabilizing this?

@SimonSapin
Copy link
Contributor

Let’s.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Dec 14, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Dec 14, 2018
@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jan 4, 2019
@rfcbot
Copy link

rfcbot commented Jan 4, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jan 4, 2019
@rfcbot
Copy link

rfcbot commented Jan 14, 2019

The final comment period, with a disposition to merge, as per the review above, is now complete.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jan 14, 2019
bors added a commit that referenced this issue Jan 14, 2019
Stabilize core::convert::identity

r? @SimonSapin

fixes #53500

This is waiting for FCP to complete but in the interim it would be good to review.
AndrewKvalheim added a commit to AndrewKvalheim/rust-exercises that referenced this issue Mar 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. B-RFC-implemented Blocker: Approved by a merged RFC and implemented. B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants