Skip to content

Commit f298eda

Browse files
committed
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.
1 parent f4cc16b commit f298eda

File tree

1 file changed

+1
-7
lines changed

1 file changed

+1
-7
lines changed

text/3245-refined-impls.md

Lines changed: 1 addition & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -198,7 +198,7 @@ After this RFC is merged, we should warn when a user writes an impl that looks r
198198

199199
### Automatic migration for the next edition
200200

201-
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.
201+
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.
202202

203203
### Documentation
204204

@@ -355,12 +355,6 @@ There are three main options:
355355

356356
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.
357357

358-
## Do we need a soft transition?
359-
360-
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.
361-
362-
In the absence of compelling data demonstrating this, however, we should take the conservative approach of doing a soft transition.
363-
364358
# Future possibilities
365359
[future-possibilities]: #future-possibilities
366360

0 commit comments

Comments
 (0)