negative impls integrated into coherence #96
Comments
|
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. |
|
This sounds great! Related to the !Error for |
|
Ah, interesting, I hadn't considered the idea that we might use it to remove some fundamental, even if we can't remove them all. Yes, that would be good. |
|
I don't know if this works or is needed here, but let's find out @rustbot second |
rustbot
added
the
final-comment-period
|
We agreed to let this work proceed. I will create the relevant tracking issue. |
|
However, I'd like to discuss this as part of tomorrow's planning meeting. We would need a liaison, I think, and I'm not sure that @yaahc can realistically be the owner here (I think it is realistically me). |
|
(I'm willing to be liason. We should revisit official assignment of liason in future lang team meeting; today's only has two team members present.) |
…it, r=nikomatsakis Implement coherence checks for negative trait impls The main purpose of this PR is to be able to [move Error trait to core](rust-lang/project-error-handling#3). This feature is necessary to handle the following from impl on box. ```rust impl From<&str> for Box<dyn Error> { ... } ``` Without having negative traits affect coherence moving the error trait into `core` and moving that `From` impl to `alloc` will cause the from impl to no longer compiler because of a potential future incompatibility. The compiler indicates that `&str` _could_ introduce an `Error` impl in the future, and thus prevents the `From` impl in `alloc` that would cause overlap with `From<E: Error> for Box<dyn Error>`. Adding `impl !Error for &str {}` with the negative trait coherence feature will disable this error by encoding a stability guarantee that `&str` will never implement `Error`, making the `From` impl compile. We would have this in `alloc`: ```rust impl From<&str> for Box<dyn Error> {} // A impl<E> From<E> for Box<dyn Error> where E: Error {} // B ``` and this in `core`: ```rust trait Error {} impl !Error for &str {} ``` r? `@nikomatsakis` This PR was built on top of `@yaahc` PR rust-lang#85764. Language team proposal: to rust-lang/lang-team#96
|
As an experiment I implemented impl !Future for ! {}
impl !Future for () {}
impl<E: ?Sized> !Future for Result<!, E> {}
impl<E: ?Sized> !Future for Result<(), E> {}There was figuring out to do regarding |
|
This is basically all set but we just need to create the real tracking issue. @pnkfelix will serve as liaison. There is a repository here for those interested in more details: |
I couldn't find a link to the repo in the mdbook you linked but was able to guess it from the url: https://github.com/rust-lang/negative-impls-initiative |
|
Closing in favor of https://github.com/rust-lang/lang-team/issues/136 |
Proposal
Summary and problem statement
@yaahc and I have been investigating the possibility of integrating 'negative impls' into coherence. The precise motivation is to enable
and then, in a downstream crate, support
Note that this would not permit
where T: !Traitsyntax, although we could in principle support that, though we would have to be careful about what it means (in particular, it would be relatively easy to support if what it means is "there is a negative impl").Motivation, use-cases, and solution sketches
Prioritization
Fits under error handling, and is also a kind of core enabler likely to arise elsewhere
Links and related work
Initial people involved
nikomatsakis, yaahc
What happens now?
This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: