Warn about more ignored bounds in type aliases #48020
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
pietroalbini
added
the
S-waiting-on-review
| @@ -0,0 +1,18 @@ | |||
| warning[E0122]: bounds are ignored in type aliases | |||
There was a problem hiding this comment.
Nit: maybe "generic bounds" instead just "bounds"?
Just "bounds" looks like something is missing to me. Not sure.
|
r=me after maybe fixing the nit |
|
✌️ @RalfJung can now approve this pull request |
petrochenkov
added
S-waiting-on-author
|
Oh fancy, I had no idea bors supports delegation like this. oO I didn't want to write "type and lifetime bounds", hence my choice of words. I like "generic bounds", thanks for the suggestion! |
|
Let's see if this works... |
|
📌 Commit ac183f8 has been approved by |
bors
added
S-waiting-on-bors
|
Oh, seems like you don't usually put at |
|
@RalfJung |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit ac183f8 has been approved by |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit ac183f8 has been approved by ``` |
|
lol indeed. Now poor bors is confused. Also, does it escape things properly? What about @bors r=petrochenkov |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit ac183f8 has been approved by |
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit ac183f8 has been approved by |
|
Just to be on the safe side, if you propose making it an error, what will happen to code like this, will it continue to be accepted?: use std::ops::Index;
type Output<I, T> = <I as Index<T>>::Output; |
|
I think so -- this checks bounds in the binders of type aliases, not touching the code it expands to. I assume you bring this up because it actually works? All I'm advocating for is the compiler tell us when we write something that it doesn't support. |
…chenkov Warn about more ignored bounds in type aliases It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately. I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)
|
Yes it works, but my intuition would be that the bound is required in the type alias definition there, and the compiler is doing the opposite, enforcing the form without bound. |
|
The current behavior of type aliases is essentially a syntactic expansion. It's more like a macro. Type bounds are checked later. (That's my interpretation anyway, please correct me if that's wrong.) I do agree that this is somewhat unexpected. However, changing it is backwards-incompatible. So I figured we could at least try to reduce the confusion by telling people when we ignore what they write, e.g. if they do which actually doesn't mean the I suppose what you're saying is that instead of forcing (well, linting) the bounds to be empty, we could lint them to exactly match whatever is required to make sense of the type in the right? I agree that'd be somewhat nicer and more compatible with an eventual future where these bounds are actually checked (at def'n time) and enforced. Unfortunately, I have no idea how to go about implementing that; it seems pretty complicated. Do you think this is a realistic thing to do, and we should rather abort/revert this MR to not have people that want to adhere to the lint change their code twice? Notice however that for type bounds, we already warn. This just adds the same warning to lifetime bounds. |
|
In the long run I think the bound requirement is correct, but this has already turned quite the other way (with regular bounds), so it doesn't matter to stop just this PR. |
It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately.
I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)