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
Small wording tweaks
  • Loading branch information
@tmandry
tmandry committed May 12, 2022
commit d0359986c19f38d28c126e73ae57fcce2c0e137d
8 changes: 3 additions & 5 deletions text/3245-refined-impls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -177,13 +177,13 @@ Each associated item defined in the implementation meet the following conditions
* Each where clause must be implied by the where clauses on the trait itself and/or the associated function in the trait definition, where "implied" is limited to supertrait and outlives relations. _This would be expanded to all [implied bounds] when that feature is enabled._
* Must not be marked `unsafe` unless the trait definition is also marked `unsafe`.

When an item in an impl meets these conditions, we say it is a valid refinement of the trait item.
When an item in an impl meets these conditions, we say it is a _valid refinement_ of the trait item.

[implied bounds]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html

### Using refined implementations

Refined APIs are available anywhere knowledge of the impl being used is available. If the compiler can deduce a particular impl is being used, its API is available for use by the caller. This includes UFCS calls like `<MyType as Trait>::foo()`.
Refined APIs are available anywhere knowledge of the impl being used is available. If the compiler can deduce a particular impl is being used, its API as written is available for use by the caller. This includes UFCS calls like `<MyType as Trait>::foo()`.

## Transitioning away from the current behavior

Expand Down Expand Up @@ -277,8 +277,6 @@ Should the `nth` method also be considered `const fn`?
# Drawbacks
[drawbacks]: #drawbacks

> Why should we *not* do this?

## Accidental stabilization

For library authors, it is possible for this feature to create situations where a more refined API is *accidentally* stabilized. Before stabilizing, we will need to gain some experience with the feature to determine if it is a good idea to allow refined impls without annotations.
Expand Down Expand Up @@ -316,7 +314,7 @@ While we could postpone the question of whether to allow this indefinitely, we a

We could allow `#[refine]` on individual aspects of a function signature like the return type, where clauses, or argument types. This would allow users to scope refinement more narrowly and make sure that they aren't refining other aspects of that function signature. However, it seems unlikely that API refinement would be such a footgun that such narrowly scoping is needed.

Going in the other direction, we could allow `#[refine]` on the impl itself. This would remove repetition in cases where an impl refines many items at once. It seems unlikely that this would be desired frequently enough to justify it.
Going in the other direction, we could allow `#[refine]` on the impl itself. This would remove repetition in cases where an impl refines many items at once. It is unclear if this would be desired frequently enough to justify it.

# Prior art
[prior-art]: #prior-art
Expand Down