<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4" face="monospace">No :)<br>
      <br>
      It was discussed why not to use bare "catch" on the EG list. 
      "Case catch" is slightly different, but I'd like to explain why
      this is not in the spirit of the feature.  <br>
      <br>
      To recap one of the reasons we rejected bare `catch`: because it
      is asking a question _about the selector_ (did evaluating the
      selector throw), not about the _block_ (did something in this
      switch block throw.)  If we called it catch, this would surely be
      confusing.  <br>
      <br>
      The essence of switch is "evaluate a thing, then do one of the
      following things as a result."  With an exhaustive switch with no
      fall through, its "exactly one thing"; let's go with that as our
      model: evaluate a thing, then do exactly one of the following
      things.  <br>
      <br>
      We pick which thing to do based on case selectors.  Currently we
      have case selectors for constants, patterns, and catch-all
      (default).  Each of these selectors should refer back _to the
      computation_ that is the switch selector.  A `case
      <constant>` says "did it evaluate to this constant."  A
      `case <pattern>` says "did it evaluate to something that
      matches this pattern."  A `case throws <pattern>` says "did
      it throw something that matches this pattern."  But "case catch"
      would be asking "did it evaluate to something that catches this
      exception", which doesn't really even make sense.  <br>
      <br>
      Further, I know we are all used to the word "catch" from
      try-catch, but "catch" is a very imperative framing, which comes
      from a day where language control constructs were all statements
      (while, for, if, try, etc), not expressions.  Over the last 30
      years we've learned that statements suck.  (Because, expressions
      compose, and statements don't, and composition is the best tool we
      have.)  <br>
      <br>
      So I think the desire to hold onto "catch" here (in addition to
      the problems discussed on the EG list) is mostly skating to where
      the puck *was*, rather than where it is *going*.  <br>
      <br>
      <br>
    </font><br>
    <div class="moz-cite-prefix">On 2/19/2024 9:18 AM, Patrick Doyle
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANUDhE=NgOn5pXOFA=8NaoakbvNrLZQWUhpUoJfZLSFnOpZn_g@mail.gmail.com">
      
      <div dir="ltr">
        <div>In Brian's "Uniform handling of failure in switch", he
          proposes the syntax "case throws". I see the motivation (it
          certainly reads nicely) but since such clauses are catching
          exceptions, wouldn't it be more in line with the rest of the
          language to use "case catch"?</div>
        <div><br>
        </div>
        <div>This would also serve to preserve the word "throws" for its
          usual purpose if ever "switch ... throws" becomes a thing.</div>
        <div><br>
        </div>
        <div>
          <div>
            <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>
              Patrick Doyle<br>
              <a href="mailto:p.r.doyle@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">p.r.doyle@gmail.com</a></div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>