impl Not for !

[dtolnay]

The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form if !$cond {...}, even without feature(never_type) on a stable compiler. Namely if $cond contains a return or break or similar diverging expression, which would otherwise be perfectly legal in boolean position, the code previously failed to compile with:

error[E0600]: cannot apply unary operator `!` to type `!`
   --> library/core/tests/ops.rs:239:8
    |
239 |     if !return () {}
    |        ^^^^^^^^^^ cannot apply unary operator `!`

[dtolnay]

It looks like highfive hasn't assigned this.
r? rust-lang/libs-api

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

Nominating for the lang team because the libs-api team would like to check whether lang considers it a lang matter if we add impls of traits for !.

Note in particular that this will be visible in stable.

[scottmcm]

Is this the first trait impl on ! for which there's an associated type?

Output = ! does seem reasonable for Not, but I wonder if this would be a good time to think about how to pick it more generally. Like Iterator for ! is particularly non-obvious to me.

So I don't really have any particular concern here, but this seems like it's setting a precedent for other things -- does Add for ! come next? -- where I'm not sure exactly what form it should have.

If there was going to be a lang thing here, it could be that the type checker just was smart about ! specifically. Since we might want something like impl<T> Add<!> for T and impl<T> Add<T> for !, but we can't have both of those. Maybe the answer there is that we want features for that overlap anyway?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Amanieu]

Regarding Add, can we just have a single impl Add<!> for ! and let type coercion/inference do the rest?

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[m-ou-se]

@bors r+

[bors]

📌 Commit 3136c5f has been approved by m-ou-se