Provisionally add let/var...else to the design overview
#1388
Conversation
| **Note:** This is provisional, this design has not been through the proposal | ||
| process yet. |
There was a problem hiding this comment.
Can you help me understand the motivation for documenting this prior to formally proposing/adopting it? Unlike the initial stuff in #83 or your more recent design doc updates, this doesn't seem like it will help bootstrap the language design or provide important context, and unlike the discussion of const in #1378, I don't think this is something people will be asking about if we don't address it.
There was a problem hiding this comment.
It actually came up because I was trying to figure out what belonged in "refutable patterns" versus "match control flow statement" when working on the design overview. (Resolution: the if clause is part of the case part of a match, not refutable patterns in general because they aren't as clearly useful for let/var...else.) It seemed like there were any design questions left for this feature after the Discord discussion, so I thought I'd just put a quick write up to show the direction we were thinking. I'm happy to follow this up with a real proposal, but I didn't expect that the leads would have the bandwidth to land one of those before the going-public talk, and I wanted to flesh out this design overview with as much of what we were thinking as I could before it got a lot of viewers.
I do think it is helpful to start pinning this down for thinking about the pattern matching (and possibly error handling) design space.
There was a problem hiding this comment.
FWIW, I'm happy either way, no strong opinion.
I have lots of questions in this space, but I'm fine with the provisional writeup here. I don't think its going to cause deep misunderstandings even if we end up changing anything, or be off-putting for folks in any way absent a full rationale.
I wasn't part of the Discord discussion, I'd defer to @zygoloid and @KateGregory here.
There was a problem hiding this comment.
FWIW I'm not worried about misunderstandings, I'm worried about anchoring.
For example, I think there's at least one major design question that the Discord discussion doesn't really address, which is 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, but I think this being in the language design, even provisionally, will tend to steer us away from considering them.
I understand the desire to put as much of what we're thinking as possible in front of people when we go public, but I don't think this is the right venue for that. docs/design should be the current actual design of Carbon, as determined by the evolution process, not our informal thoughts about where the evolution process will go in the future.
There was a problem hiding this comment.
@geoffromer: Writing a propsal here: #1871 (WIP).
| **Note:** This is provisional, this design has not been through the proposal | ||
| process yet. |
There was a problem hiding this comment.
FWIW, I'm happy either way, no strong opinion.
I have lots of questions in this space, but I'm fine with the provisional writeup here. I don't think its going to cause deep misunderstandings even if we end up changing anything, or be off-putting for folks in any way absent a full rationale.
I wasn't part of the Discord discussion, I'd defer to @zygoloid and @KateGregory here.
|
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 |
github-actions
bot
added
the
inactive
|
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. |
Discussed in #pattern-matching in Discord.