Carrier trait (third attempt) #35777
Conversation
Allows use with `Option` and custom `Result`-like types.
|
cc @rust-lang/lang |
| let sub_expr = self.signal_block_expr(hir_vec![], | ||
| sub_expr, | ||
| e.span, | ||
| hir::PopUnstableBlock, |
There was a problem hiding this comment.
should this really be I see, unstable, of course. I read this as unsafe.hir::PopUnstableBlock? I'd expect hir::DefaultBlock.
|
@nrc code looks good to me, it'd be nice though to add a test regarding the type inference effects of |
|
r=me with test -- though there remains the policy question. I think it makes sense to get the carrier trait in, and then debate about improving it -- I guess in the interim people can use |
nrc
force-pushed
the
carrier3
branch
2 times, most recently
from
080885a
to
5aa89d8
Compare
|
📌 Commit 5aa89d8 has been approved by |
The dummy impl should ensure the same type checking behaviour as having other (real) Carrier impls.
|
Wait, the RFC did not include Carrier, but this is getting merged anyway? |
|
@steveklabnik Due to type inference issues, we can't stabilise |
|
@steveklabnik right, as @nrc said, the intention is that if we will write an RFC with the actual design for |
|
Thanks both! I get it now. |
|
📌 Commit c32456d has been approved by |
Carrier trait (third attempt) This adds a `Carrier` trait to operate with `?`. The only public implementation is for `Result`, so effectively the trait does not exist, however, it ensures future compatibility for the `?` operator. This is not intended to be used, nor is it intended to be a long-term solution. Although this exact PR has not been through Crater, I do not expect it to be a breaking change based on putting numerous similar PRs though Crater in the past. cc: * [? tracking issue](#31436) * [previous PR](#35056) * [RFC issue](rust-lang/rfcs#1718) for discussion of long-term Carrier trait solutions. r? @nikomatsakis
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Perhaps it's a bit late since this already got merged, but shouldn't there be a comment explaining why an impl for a dummy type exists? I assume that some people already know this, but others would not (like me :) ).
This adds a
Carriertrait to operate with?. The only public implementation is forResult, so effectively the trait does not exist, however, it ensures future compatibility for the?operator. This is not intended to be used, nor is it intended to be a long-term solution.Although this exact PR has not been through Crater, I do not expect it to be a breaking change based on putting numerous similar PRs though Crater in the past.
cc:
r? @nikomatsakis