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

[rscircus]

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]

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

[josh11b]

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

[rscircus]

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]

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]

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]

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: https://github.com/carbon-language/carbon-lang/pull/1874

[rscircus]

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

[geoffromer]

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]

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.

[rscircus]

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

[rscircus]

So, maybe you can send me a screenshot of the discussion @josh11b mentioned in https://github.com/carbon-language/carbon-lang/pull/1388#issue-1305059495 ? I'd really like to get https://github.com/carbon-language/carbon-lang/pull/1871 out of its draft state and also close https://github.com/carbon-language/carbon-lang/pull/1388 ...

From https://github.com/carbon-language/carbon-lang/issues/2165

[rscircus]

@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]

@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]

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 ...

[josh11b]

Should this still be a draft?

[josh11b]

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]

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]

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 https://github.com/carbon-language/carbon-lang/pull/1871#issuecomment-1302558938, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI46CVQXMDC2YY2DZX2ZGDWGQFLNANCNFSM55I47I3Q . You are receiving this because you commented.Message ID: @.***>

[github-actions[bot]]

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[bot]]

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.