Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102260 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 99461 invoked from network); 14 Jun 2018 15:52:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Jun 2018 15:52:36 -0000 Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-wm0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:39881] helo=mail-wm0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E9/CB-29356-34F822B5 for ; Thu, 14 Jun 2018 11:52:36 -0400 Received: by mail-wm0-f54.google.com with SMTP id p11-v6so12903434wmc.4 for ; Thu, 14 Jun 2018 08:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pdzhCHCOAi4ogGglFAARF65nmy+vLxhzMNrx6RSm4xg=; b=k4tJEqy+QOjzzOc2jR72C8uKx0d08AMi1nwTh75qaqoPCJhnuL9MFpH8L/3wYUy7Jj avOULY2UIVNTP7u4HtwcmA10wfBiziXqRsnPmM6Pj1CkDYJavRUKXZ6U2gGA7muKo5rQ 9T1xjIekdocGqhA76Pa+hzwonmBSS2qq2mktcxW0QYLi24wN17qiI6NabyWYxKeNq7Vu 8vIsop1T0xQPPmd706k3tUctIzoDPP4GR+gyVHqBoV59dbipetYWC4pRLG2IpeMKU7j4 srVwAVKC70+3puJY3crC9Wzoim5Lo+QNkOUzSZCPC3fZgbLp/Kk5tUDjgBhTdsXXK0Fv 1qYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pdzhCHCOAi4ogGglFAARF65nmy+vLxhzMNrx6RSm4xg=; b=O7AKC96n2hY2Xaz51XwKUacr/545tGkj/PXWy/p/jjVybhDUhEFDlKIskmHg7uvwe0 Qi6fyUoC8P9FLuT5shtCA7baO+7HrB9YJABpkC9TzGzg8Opj6jta7Z7hyG/eUUJpiNC3 j2owqQb1+GeEQPkUAtD4F/v6ZrEbtbQY3f3Cn6C2QUh93MHJG3EyEY9vsjiC0cLy+feM FNqYtEjzVSK3y+kX649eMKn/P7RCwe5F7ja9KEoZIbOna9b27knXAXeiY4ODXeuGvrzT Q2F70wUYCq3mEJRjxTm8A4jmhrOHHqienLxOz11KxVFy1F4NP1RgoFuSNPdwE+GwNC9y nESA== X-Gm-Message-State: APt69E0GoxEMXFTo3/wFYgvOIm2bEsG1pbXHZZ5nVV0SQwm5Z2truQLE BAzjHBQr/2CFQfLzsNWn5lpnKzfszM3TJFuCF0I= X-Google-Smtp-Source: ADUXVKL6Cb5ks0FZ2SmoygKKgy23mlBgijOnvF+wFjU4HgfhtW/Lo8V/JYJDFabl31pFT9/ASTNpOWmBN9WbeV2gOv0= X-Received: by 2002:a50:de0c:: with SMTP id z12-v6mr3112488edk.245.1528991552786; Thu, 14 Jun 2018 08:52:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:8d55:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 08:52:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jun 2018 16:52:32 +0100 Message-ID: To: Sara Golemon Cc: Nikita Popov , PHP internals Content-Type: multipart/alternative; boundary="0000000000005e5462056e9c164c" Subject: Re: [PHP-DEV] Strict switch statements From: rowan.collins@gmail.com (Rowan Collins) --0000000000005e5462056e9c164c Content-Type: text/plain; charset="UTF-8" On 14 June 2018 at 15:48, Sara Golemon wrote: > Agree that it's more likely to be all-or-not within a switch block. > If I could step through my thinking in putting it on the case > statement however, I applied two starting rules: > 1. Avoid adding new reserved symbols/keywords. > 2. Try to make it read naturally. > > I actually did consider Rowan's suggestion `switch (expr) use (===) > {}`, but I didn't feel like it satisfied #2 well. > I always read it in my head as "switch on expression using the === operator". There is a bit of a punctuation pileup, though. > I'll be honest, I didn't realize the fall-through behavior was a > learning curve issue. This block scoping would address that, but I > wonder if we could make use of break/continue. The former's meaning > being obvious enough, the latter allowing us to either fall through to > the next case or possibly continuing evaluating conditionals. Yeah, annoyingly "continue" is actually valid in switch statements, as a confusing synonym of "break", because I always thought it would be nice if you had to balance every non-empty case with either "break" or "continue". It's not just the learning curve that's a problem, it's really easy to write subtly broken code with an accidental fall-through. I was just telling a colleague that I've made this mistake before: //Before: no break needed because there's a return switch ( $foo ) { case 1: return true; default: bar(); } //After: should have added a break, but didn't notice until something went wrong switch ( $foo ) { case 1: if ( $something ) { return true; } default: bar(); } I think a lot of people would find a syntax with { ... } blocks much more familiar. One thing to consider is what actually is the "mission statement" of the switch/match/whatever - what makes it "better" than a chain of if-elseif blocks? Meanwhile, someone just posted this on Stack Overflow https://stackoverflow.com/q/50860319/157957 where someone was trying to use <= in a switch statement! Regards, -- Rowan Collins [IMSoP] --0000000000005e5462056e9c164c--