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.

Sign up for GitHub

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

Refined trait implementations #3245

Merged
merged 8 commits into from
Aug 26, 2022
Merged

Refined trait implementations #3245

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
ef84eb4
Refined trait implementations
tmandry Mar 22, 2022
d035998
Small wording tweaks
tmandry May 12, 2022
409f3dd
Revise options for `#[refine]`
tmandry May 12, 2022
166024a
Refactoring, Bounding refined items
tmandry Jun 9, 2022
f4cc16b
Interaction with Method dispatch, Unsatisfiable trait members
tmandry Jun 9, 2022
f298eda
Remove unresolved question about a soft transition
tmandry Aug 18, 2022
5311c59
Clarify the need for #[refine] with unsafe
tmandry Aug 18, 2022
3a97726
Add tracking issue
tmandry Aug 18, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Remove unresolved question about a soft transition 
It doesn't seem realistic that we will avoid doing a soft transition at
all. Since it was decided that we would definitely adopt #[refine] in
the current edition, I don't think this question is relevant anymore.
  • Loading branch information
@tmandry
tmandry committed Aug 18, 2022
commit f298eda6ff99e173f7152ad3d9037cbc3de13ac9
8 changes: 1 addition & 7 deletions text/3245-refined-impls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -198,7 +198,7 @@ After this RFC is merged, we should warn when a user writes an impl that looks r

### Automatic migration for the next edition

We may want to upgrade the above lint to an error in 2024 or make refinement the default without any attribute at all. In either of these cases, we should have an automatic edition migration that rewrites users' code to preserve its semantics. That means we will replace trait implementations that look refined with the original API of the trait items being implemented.
We may want to upgrade the above lint to an error in 2024 or make refinement the default without any attribute at all. In either case, we should have an automatic edition migration that rewrites users' code to preserve its semantics. That means we will replace trait implementations that look refined with the original API of the trait items being implemented.

### Documentation

Expand Down Expand Up @@ -355,12 +355,6 @@ There are three main options:

It would help to do an analysis of how frequently "dormant refinements" occur on crates.io today, and of a sample of those, how many look accidental and how many look like an extended API that a crate author might have meant to expose.

## Do we need a soft transition?

In "Transitioning away from the current behavior" above we describe doing a soft transition. However, the analysis on crates.io just described _could_ reveal that "dormant refinements" are almost never a mistake, and a `#[refine]` attribute is not needed in future editions. In that case we may want to reconsider the soft transition approach for existing editions.

In the absence of compelling data demonstrating this, however, we should take the conservative approach of doing a soft transition.

# Future possibilities
[future-possibilities]: #future-possibilities

Expand Down