owned this note
owned this note
Published
Linked with GitHub
# Negative trait impls FCP
This write-up describes the `negative_impls` feature-gate. This functionality is somewhat ad-hoc and not (yet!) covered by an RFC. It was added semi-urgently in order to close an existing soundness hole.
## Negative impls
With the feature gate `negative_impls`, we now permit negative impls as well as positive ones:
```rust
impl<T: ?Sized> !DerefMut for &T { }
```
Negative impls indicate a semver guarantee that the given trait will not be implemented for the given types. Negative impls play an additional purpose for auto traits, described below.
Negative impls have the following characteristics:
* They do not have any items.
* They must obey the orphan rules as if they were a positive impl.
* They cannot "overlap" with any positive impls.
## Orphan and overlap rules
Negative impls must obey the same orphan rules as a positive impl. This implies you cannot add a negative impl for types defined in upstream crates and so forth.
Similarly, negative impls cannot overlap with positive impls, again using the same "overlap" check that we ordinarily use to determine if two impls overlap. (Note that positive impls typically cannot overlap with one another either, except as permitted by specialization.)
## Interaction with auto traits
Auto traits generally work as follows. For a given auto trait `AutoTrait`, and a given struct/enum/union `Foo<..>`, we check if there is any impl (positive or negative) of `AutoTrait` for `Foo`. If there is not, then we add a default impl of the form:
```rust
impl AutoTrait for Foo
where
FieldType0: AutoTrait,
..,
FieldTypeN: AutoTrait,
{ }
```
You might wish to override this for two reasons:
* To declare that `Foo: AutoTrait` is true with diferent where clauses, in which case you write a positive impl like `impl AutoTrait for Foo where ... { }`
* To declare that `Foo: !AutoTrait`, in which case you write `impl !AutoTrait for Foo { }`.
Both of them will suppress the default impl.
Note that, at present, there is no way to indicate that a given type does not implement an auto trait *but that it may do so in the future*. For ordinary types, this is done by simply not declaring any impl at all, but that is not an option for auto traits. A workaround is that one could embed a marker type as one of the fields, where the marker type is `!AutoTrait`.
## Immediate uses
Negative impls are used to declare that `&T: !DerefMut` and `&mut T: !Clone`, as required to fix the soundness of `Pin` described in [#66544](https://github.com/rust-lang/rust/issues/66544).
This serves two purposes:
* For proving the correctness of unsafe code, we can use that impl as evidence that no `DerefMut` or `Clone` impl exists.
* It prevents downstream crates from creating such impls.
## What are we committing to here?
Basically nothing -- we could remove the negative impls for `DerefMut` and `Clone`, though we'd have to resolve the unsoundness some other way. Downstream users cannot add their own negative impls without a feature gate, and having negative impls doesn't allow them to do anything they couldn't have otherwise done.
## Future extensions
This change is intentionally minimal. In particular, it does not enable any *new* Rust code to compile; its effect is believed to be simply **disallowing** impls like:
```rust
impl DerefMut for &LocalType { }
impl Clone for &mut LocalType { }
```
However, we would at some point like to move this into a full-fledged feature. Some possible extensions would include:
### Allowing coherence to take negative impls into account
For example, we might add
```rust
impl<T: ?Sized> !Copy for Box<T> { }
```
in order to affirmatively declare that `Box<T>` will never implement `Copy`. This would permit downstream creates to leverage that knowledge in their impls, meaning that the following code would compile (which doesn't today):
```rust
trait MyTrait { }
impl<T: Copy> MyTrait for T { }
impl MyTrait for Box<u32> { }
```
### Preferring explicit negative declarations to crate-local reasoning
Similar to the above, we might start to phase out the "crate-local" reasoning that we use today for negative logic. In particular, we currently permit negative reasoning for types that were defined in the current crate. We could deprecate that in favor of explicit negative impls, meaning that a program like the following would get warnings:
```rust
struct MyStruct { }
trait MyTrait { }
impl<T: Copy> MyTrait for T { }
impl MyTrait for MyStruct { }
```
The warnings could be silenced by adding an explicit:
```rust
impl !Copy for MyStruct { }
```
This would make explicit a requirement that is already *implicit* -- i.e., it would not presently be possible to add a `impl Copy for MyStruct` without breaking the orphan rules.
However, this may not make sense to do -- after all, with specialization, it *would* be possible to add `impl Copy for MyStruct`. But there may be other cases (have to think about it...) where it makes sense to request users to make negative reasoning explicit.
At minimum, this gives users the *option* of doing so, if they wish.
### Permit `T: !Trait` where clauses
We could conceivably permit where clauses like `where T: !Trait`. Such a where clause would onlly be satisfied if we can find an explicit negative impl that satisfies it.
Therefore, consider this example:
```rust
trait MyTrait { }
impl MyTrait for u32 { }
impl !MyTrait for f32 { }
```
Here, the following where-clauses would be true/false:
| Trait and type | Provable? |
| --- | --- |
| `u32: MyTrait` | :white_check_mark: |
| `u32: !MyTrait` | :x: |
| `f32: MyTrait` | :x: |
| `f32: !MyTrait` | :white_check_mark: |
| `String: MyTrait` | :x: |
| `String: !MyTrait` | :x: |
Google Drive
Gist
Clipboard
Sign in with Wallet
