Initiative: ? traits, try blocks, yeet exprs, oh my
#160
Labels
final-comment-period
The FCP has started, most (if not all) team members are in agreement
major-change
Major change proposal
T-lang
to-announce
Not yet announced MCP proposals
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. |
|
@rustbot second |
rustbot
added
the
final-comment-period
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
May 1, 2022
Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in rust-lang#84277 (comment) doesn't accidentally close us off from the possibility of doing this in future, as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this, to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization, but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: rust-lang/lang-team#160 (comment) Tracking issues - Lang, rust-lang#96373 - Libs-api, rust-lang#96374
workingjubilee
pushed a commit
to tcdi/postgrestd
that referenced
this issue
Sep 15, 2022
Add `do yeet` expressions to allow experimentation in nightly Two main goals for this: - Ensure that trait restructuring in rust-lang/rust#84277 (comment) doesn't accidentally close us off from the possibility of doing this in future, as sketched in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-yeet - Experiment with the *existence* of syntax for this, to be able to weight the syntax-vs-library tradeoffs better than we can right now. Notably the syntax (with `do`) and name in this PR are not intended as candidates for stabilization, but they make a good v0 PR for adding this with minimal impact to compiler maintenance or priming one possible name choice over another. r? `@oli-obk` The lang `second` for doing this: rust-lang/lang-team#160 (comment) Tracking issues - Lang, rust-lang/rust#96373 - Libs-api, rust-lang/rust#96374
|
Per the new process we've adopted, i'm going to close this issue and delegate to existing tracking issues like #84277 and #31436. |
icecream17
added a commit
to icecream17/words
that referenced
this issue
Nov 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Proposal
Summary and problem statement
Getting existing error handling capabilities to stable, and exploring future possibilities to ensure compatibility.
Motivation, use-cases, and solution sketches
This is basically https://rust-lang.github.io/rfcs/0243-trait-based-exception-handling.html -- while
?is available on stable, the traits behind it are not,tryblocks are not, and there's continued interest (https://areweyeetyet.rs/) in exploring some of the future possibilities it brought up.There's sortof a defacto initiative going on here -- see the mention in these meeting notes https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2022-03-09-lang-roadmap.md#q-which-active-initiatives-are-missing -- but it seems like it would be helpful to have one to track it explicitly.
Links and related work
Some examples of things that could be included here:
try_trait_v2, A new design for the?desugaring (RFC#3058) rust#84277 (comment)tryblocks to stable, having resolved one major open question in ResolvingOk-wrapping fortryblocks rust#70941 but with more annotation questions needing work as discussed in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/try.20blocks/near/275118361yeetexpressions to ensure the trait designs being discussed can handle them and gaining unstable experience to see whether the extra syntax pulls its weight over existing macro approaches.yeetexperimentally compiler-team#501, but it appears they'd like more of a lang second first, as "the compiler change seems trivial and well motivated if the language change is ok" (https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Add.20.60yeet.60.20experimentally.20compiler-team.23501/near/276746889).Initial people involved
What happens now?
This issue is part of the lang-team initiative process. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open proposals 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: