Remove from_iterator_instead_of_collect lint.#16923
Open
kpreid wants to merge 1 commit intorust-lang:masterfrom
Open
Remove from_iterator_instead_of_collect lint.#16923kpreid wants to merge 1 commit intorust-lang:masterfrom
from_iterator_instead_of_collect lint.#16923kpreid wants to merge 1 commit intorust-lang:masterfrom
Conversation
Since the 2021 edition of Rust, `FromIterator` is in the prelude and is intended to be used in at least certain cases. Per [RFC 3114]: > The documentation for `FromIterator`'s `from_iter()` method currently reads: > > > `FromIterator::from_iter()` is rarely called explicitly, and is > > instead used through `Iterator::collect()` method. See > > `Iterator::collect()`'s documentation for more examples. > > However, it is reasonably common that type inferencing fails to infer > the full type of the target type, in which case an explicit type > annotation or turbofishing is needed (such as > `iter.collect::<Vec<_, _>>()` -- the type of the iterator item is > available, so wildcards can be used for this). In these cases, > `Vec::from_iter(iter)` can be a more concise and readable way to spell > this, which would be easier if the trait was in scope. Currently, the `from_iter_instead_of_collect` lint always lints in favor of using `collect()` when possible. Issue 7213 is open with the intent of changing the lint to only lint when no turbofish is needed on `collect()`; however, no progress has been made on that since 2021. Furthermore, whether type inference succeeds can be fragile, easily changing as a program is edited. In my opinion, Rust programmers should not be steered towards programs which contain only the minimum number of type annotations and other type constraints; they should be allowed (and even sometimes encouraged) to write programs with more explicit types. There are also several long-standing suggestion-causes-error bugs. I believe that `from_iter_instead_of_collect`, in its current form and perhaps in any form, does not make code better. This commit removes it. [RFC 3114]: https://github.com/rust-lang/rfcs/blob/master/text/3114-prelude-2021.md#fromiterator
Collaborator
|
r? @llogiq rustbot has assigned @llogiq. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Lintcheck changes for 8c034f0
This comment will be updated if you push new changes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since the 2021 edition of Rust,
FromIteratoris in the prelude and is intended to be used in some cases. Per RFC 3114:Currently, the
from_iter_instead_of_collectlint always lints in favor of replacingFromIterator::from_iter()withIterator::collect()when possible. #7213 is open with the intent of changing the lint to only lint when no turbofish is needed oncollect(); however, no progress has been made on that since 2021. Furthermore, whether type inference succeeds can be fragile, easily changing as a program is edited. In my opinion, Rust programmers should not be steered towards programs which contain only the minimum number of type annotations and other type constraints; they should be allowed (and even sometimes encouraged) to write programs with more explicit types. There are also several long-standing suggestion-causes-error bugs.I believe that
from_iter_instead_of_collect, in its current form and perhaps in any form, does not make code better. This commit removes it.from_iter_instead_of_collectfeels like a blanket ban of theFromIteratortrait #7213.clippy::from-iter-instead-of-collectforFxHashSet#9315.changelog: [
from_iter_instead_of_collect]: removed