Introduce `var`/`let`-`else`-statement #1871

rscircus · 2022-08-01T21:16:10Z

As implied in PR #1388 and requested in #1758 this proposal introduces the rationale behind the simplification of a common error-handling pattern, informally known as let-else statement (or var-else statement). It can be interpreted as syntactic sugar for a match-statement where the non-matched case diverges. Hence, the usage as error-handling pattern.

rscircus · 2022-08-01T21:17:40Z

@josh11b - this needs the labels proposal and WIP. Can't add them unfortunately.

josh11b · 2022-08-01T21:26:50Z

Looking at the files changed, looks like this is still a work in progress, so I've made it a draft proposal.

rscircus · 2022-08-01T21:33:01Z

Looking at the files changed, looks like this is still a work in progress, so I've made it a draft proposal.

Yep. Still putting some thought into this right now. Especially, into @geoffromer's comment "whether we should have this feature at all. There may be other combinations of pattern matching/error handling features which would make this one superfluous".

rscircus · 2022-08-01T22:35:37Z

OK, so far so good. I added another suggestion for this pattern:

let (x: i32, true) = F(1) else {
  // Can't use `x` here.
  return false;
}

=>

let (x: i32, true) = F(1) ?: {  return false; }

A "compressed" ternary operator omitting the happy path. It'll be very familiar to all curly-brace language programmers, I think.

rscircus · 2022-08-01T22:44:19Z

Considering @geoffromer comment, I think, it can be, that depending upon how or is implemented, this might work out of the box:

var/let (x: i32, true) = F(1) or { return; };

rscircus · 2022-08-01T22:49:52Z

Looking at the files changed, looks like this is still a work in progress, so I've made it a draft proposal.

If the label recommendation of WIP changed, it might make sense to update the equivalent line in the template. I'll throw in a PR in a sec.

Edit: Here it is: #1874

rscircus · 2022-08-02T09:00:11Z

More food for thought: https://www.hillelwayne.com/post/python-abc/ - HN view on this: https://news.ycombinator.com/item?id=32314368

geoffromer · 2022-08-03T19:12:48Z

This PR is marked "ready for review", but it's still in the "Draft" column of the "Proposals" project (see "Projects" on the right side of the GitHub window). If you intend this to be ready for review, I think it needs to be moved to the "RFC" column. Otherwise, the PR should be marked as a draft (use the "convert to draft" link in the "Reviewers" section).

It's unfortunate that we track this information in two places, but I'm not sure if there's a better option :-(

jonmeow · 2022-08-12T18:05:34Z

This PR is marked "ready for review", but it's still in the "Draft" column of the "Proposals" project (see "Projects" on the right side of the GitHub window). If you intend this to be ready for review, I think it needs to be moved to the "RFC" column. Otherwise, the PR should be marked as a draft (use the "convert to draft" link in the "Reviewers" section).

It's unfortunate that we track this information in two places, but I'm not sure if there's a better option :-(

I'm assuming that this is intended to be in rfc given the "ready for review", and marking it such. See #1898 for some context.

josh11b · 2022-08-25T22:51:04Z

proposals/p1871.md

+This statement is syntactic sugar for a set of other patterns, specifically it
+guards a code block if a requirement of this code block is violated. That is,
+there is actually no problem.


There is a problem, otherwise we should not pursue this proposal. I believe var/let-else solves a real problem, and it is important that this proposal articulate what that problem is. The problem has to do with making common programming tasks both readable and writable. The specific benefit of var/let-else is when the task has two cases:

One case which can be identified using a pattern, and the main body of the function following will be handling.

All other cases can be handled uniformly and briefly.

If code follows that pattern, then this construct has two advantages: it is concise and not going to introduce as much indenting as other constructs. Both of these help readability and writability. Consider:

match (my_container.LookUp(...)) { case .None => { return NotFound; } case .Some(result: String) => { very; long; block; of; code; return Found(processed_result); } }

compared to:

let .Some(result: String) = my_container.LookUp(...) else { return NotFound; } very; long; block; of; code; return Found(processed_result);

The big question is whether this use case is important / common. And I think that comes down to looking at examples when you would use this construct. I think the "function returns an optional" situation is one common example where this comes up. Another example is when calling a function that returns an error that this function wants to transform into a different error. Other examples would be valuable to identify.

You might want to search around for the "return early pattern" to find examples where this would be useful.

josh11b · 2022-08-25T22:56:17Z

proposals/p1871.md

+This pattern is said to improve the readability of code, compared to an
+equivalent `match` or `if` statement. It allows to keep code which handles
+violated requirements next to the requirements.


Rationales in Carbon are to be written in terms of Carbon's stated goals and principles. The proposal template has some links, the one that I think is relevant to this proposal is: [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)

josh11b · 2022-08-25T23:30:11Z

proposals/p1871.md

+-   `var`/`let` ... `or {...}`
+-   `var`/`let` ... `?: {...}` a short-circuited ternary operator
+-   `var`/`let` ... `otherwise {...}`
+-   introducer syntax: `guard var`/`let` ... `else {...}`


These alternatives should include the advantages and disadvantages of these options and a rationale for why we chose the proposal over the alternative. If you don't know, that is a good time to reach out to the community.

josh11b · 2022-08-25T23:31:00Z

proposals/p1871.md

+This proposal adds this pattern as it seems to be rather popular and simplifies
+common error-handling patterns.


It would be great to go deeper into this here.

rscircus · 2022-09-10T06:29:11Z

Marking this as draft again. Thanks @josh11b for the thorough review.

rscircus · 2022-09-20T08:57:37Z

So, maybe you can send me a screenshot of the discussion @josh11b mentioned in #1388 (comment) ? I'd really like to get #1871 out of its draft state and also close #1388 ...

From #2165

rscircus · 2022-09-20T08:58:53Z

@PramodhTVK - feel free to continue on this one. I am redirecting my energy to other FLOSS work.

Edit: Waiting 1mo until deleting https://github.com/rscircus/carbon-lang containing the branch from this PR.

enghitalo · 2022-09-20T21:42:52Z

@PramodhTVK - feel free to continue on this one. I am redirecting my energy to other FLOSS work.

Edit: Waiting 1mo until deleting https://github.com/rscircus/carbon-lang containing the branch from this PR.

What is missing??? This is the best request for carbon error handling that I see. Very similar to v lang.

zygoloid · 2022-09-21T00:19:23Z

So, maybe you can send me a screenshot of the discussion @josh11b mentioned in #1388 (comment) ? I'd really like to get #1871 out of its draft state and also close #1388 ...

micttyl · 2022-09-21T02:05:13Z

proposals/p1871.md

+transfer statement as `break`, `continue`, `return`, or a function that does not
+return.
+
+[Rust](https://github.com/rust-lang/rfcs/blob/master/text/3137-let-else.md)


Can you instead add the actual pull so that our reviewers can feel the impression at that time?

micttyl · 2022-09-21T02:12:21Z

proposals/p1871.md

+
+## Details
+
+TBD after enough C in this RFC.


RFC - Request For Comment

Hence C is Comment(s). Like yours. ;)

josh11b · 2022-11-01T22:57:53Z

Should this still be a draft?

josh11b · 2022-11-03T19:14:51Z

FYI, Rust has recently stabilized let...else, see Announcing Rust 1.65.0. On Hacker News, there are some comments saying why they are excited by this features 1, 2,

rscircus · 2022-11-08T11:32:37Z

Hey @josh11b - thanks for having a look. I pulled out of working here and encouraged @PramodhTVK to continue after that time-consuming Discord mess and refocused, as it took too much time and I didn't receive any help from whatever side I tried. However, @zygoloid helped meanwhile, as far as I see. Thank you.

Then, you can find the summary of my last thoughts on this here. I'll be having a look at Rust. Thanks again.

rscircus · 2022-11-08T19:33:32Z

Read the HN thread right now. To my eye the reaction is rather mixed. As @josh11b pointed out the fans, I'll focus a bit on the critics: Many disadvantages are pointed out. Like `match` binding the error, while it's dropped in `let-else`, many alternative solutions with similar amount of code/'reviewability', pointing out the already existing solution/match for the unhappy path using `if`, not being handy for Result types and mostly for Option types only, and the biggest point being this comment by pavon: ``` Yeah, I feel like the vast majority of the time this would be better handled by splitting out that block into a function. There are situations where there the number of parameters needed to pass in would get unwieldy, but that is where I start thinking about if all that loose state is intrinsic to the problem, or a sign that I need to refactor my datastructures. ```

…

On Thu, Nov 3, 2022, 20:15 josh11b ***@***.***> wrote: FYI, Rust has recently stabilized let...else, see Announcing Rust 1.65.0 <https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#let-else-statements>. On Hacker News <https://news.ycombinator.com/item?id=33451359>, there are some comments saying why they are excited by this features 1 <https://news.ycombinator.com/item?id=33452517>, 2 <https://news.ycombinator.com/item?id=33452556>, — Reply to this email directly, view it on GitHub <#1871 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI46CVQXMDC2YY2DZX2ZGDWGQFLNANCNFSM55I47I3Q> . You are receiving this because you commented.Message ID: ***@***.***>

github-actions · 2023-02-07T02:00:22Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label.
This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

github-actions · 2023-02-21T02:03:35Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it. \n\n\n This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

Creating new proposal: var_let-else

30a33c7

Format proposal according to guide

0b422cc

github-actions bot added proposal A proposal proposal rfc Proposal with request-for-comment sent out labels Aug 1, 2022

josh11b marked this pull request as draft August 1, 2022 21:26

rscircus mentioned this pull request Aug 1, 2022

Provisionally add let/var...else to the design overview #1388

Closed

Roland Siegbert added 2 commits August 2, 2022 00:06

Add implicit proposal from carbon-language#1388

77c2894

Add problem section

9002038

jonmeow removed the proposal rfc Proposal with request-for-comment sent out label Aug 1, 2022

Add a suggestion: '?:' and background

63f87b9

Add 'or' pattern

b7f9301

rscircus marked this pull request as ready for review August 1, 2022 22:55

jonmeow added the proposal rfc Proposal with request-for-comment sent out label Aug 12, 2022

josh11b reviewed Aug 25, 2022

View reviewed changes

josh11b mentioned this pull request Sep 7, 2022

Make var/let...else proposal #1758

Open

rscircus marked this pull request as draft September 10, 2022 06:28

rscircus mentioned this pull request Sep 19, 2022

Why is discord used for discussions? #2165

Closed

micttyl suggested changes Sep 21, 2022

View reviewed changes

github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Feb 7, 2023

github-actions bot closed this Feb 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce `var`/`let`-`else`-statement #1871

Introduce `var`/`let`-`else`-statement #1871

rscircus commented Aug 1, 2022

rscircus commented Aug 1, 2022

josh11b commented Aug 1, 2022

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 2, 2022

geoffromer commented Aug 3, 2022

jonmeow commented Aug 12, 2022

josh11b Aug 25, 2022

josh11b Aug 25, 2022

josh11b Aug 25, 2022

josh11b Aug 25, 2022

josh11b Aug 25, 2022

rscircus commented Sep 10, 2022

rscircus commented Sep 20, 2022

rscircus commented Sep 20, 2022 •

edited

Loading

enghitalo commented Sep 20, 2022

zygoloid commented Sep 21, 2022 •

edited

Loading

micttyl Sep 21, 2022

micttyl Sep 21, 2022

rscircus Sep 21, 2022

josh11b commented Nov 1, 2022

josh11b commented Nov 3, 2022 •

edited

Loading

rscircus commented Nov 8, 2022

rscircus commented Nov 8, 2022 via email

github-actions bot commented Feb 7, 2023

github-actions bot commented Feb 21, 2023

		This proposal adds this pattern as it seems to be rather popular and simplifies
		common error-handling patterns.

Introduce var/let-else-statement #1871

Introduce var/let-else-statement #1871

Conversation

rscircus commented Aug 1, 2022

rscircus commented Aug 1, 2022

josh11b commented Aug 1, 2022

rscircus commented Aug 1, 2022 • edited Loading

rscircus commented Aug 1, 2022 • edited Loading

rscircus commented Aug 1, 2022 • edited Loading

rscircus commented Aug 1, 2022 • edited Loading

rscircus commented Aug 2, 2022

geoffromer commented Aug 3, 2022

jonmeow commented Aug 12, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rscircus commented Sep 10, 2022

rscircus commented Sep 20, 2022

rscircus commented Sep 20, 2022 • edited Loading

enghitalo commented Sep 20, 2022

zygoloid commented Sep 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josh11b commented Nov 1, 2022

josh11b commented Nov 3, 2022 • edited Loading

rscircus commented Nov 8, 2022

rscircus commented Nov 8, 2022 via email

github-actions bot commented Feb 7, 2023

github-actions bot commented Feb 21, 2023

Introduce `var`/`let`-`else`-statement #1871

Introduce `var`/`let`-`else`-statement #1871

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Aug 1, 2022 •

edited

Loading

rscircus commented Sep 20, 2022 •

edited

Loading

zygoloid commented Sep 21, 2022 •

edited

Loading

josh11b commented Nov 3, 2022 •

edited

Loading