Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107573 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94669 invoked from network); 18 Oct 2019 11:09:36 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 18 Oct 2019 11:09:36 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id B6D952D20FB for ; Fri, 18 Oct 2019 01:54:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Fri, 18 Oct 2019 01:54:27 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id v2so6492136iob.10 for ; Fri, 18 Oct 2019 01:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DyLNLRunKa/+jb//OTCPzjZugrDUEbFV1TqXfCEXbWk=; b=GGymp6Lddd5wc8zZMI9juL4kp1fPDypFoGc1gOalZDQM8Md6VQKks2dXv7Q2oR3yMN tzfGXDrLG2frY/tV3gbicrmR62SOSK6bBCldvwF5veIjJXECyBzGsHE2mUldx9H2/nBM RWKHNCfAg9ASB8UxjNmegx68BoEVoaJIRUR9TNRq6hTOli6A5kpJ9Xbbcbg0FN5E35yI Ni4c8N9d3tn/ZAv4gqlfVVKjJtMBOpgiDuR34Hkwr6qYuBuaYjUUbhLM/ir8CnNSWFNX gytEOR7VTSGezRIKqhecaKQReZchrmvX+EBBpLoQhIGvLr8LEsm5HFanUTLw2w64yWs5 vX6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DyLNLRunKa/+jb//OTCPzjZugrDUEbFV1TqXfCEXbWk=; b=Lj0BFrwQLTVkHr+qfVW9inPxuR6VLjyUxveSpN98Sfwh/67fUqymwxV8ynTmKIaWrb i/6uK9yZ6fmt3zxsSdOUDAwWCRRZOuLAc3vTQd2yM3V7VCMWxgpLpmSoLnGP4YhwF0EM 13fI9yN0EMnaf0mHi67wSk6eyALYwo1SiSHARvQZuAWP6eDhJN4hxRBzc4h4/ticE/wQ WJOVv2T3XKfjdWdnxsa+1E0YjcBqScq4yUciBURfogy4reStj3bUbT+P+tUZx5XHca69 JeTHs4tKl2zqQ47r9I4SpBSq0NYGLmUhMaitxQmgJkATFYxS1azOIZ52dDlH4MiV9e6E BsuA== X-Gm-Message-State: APjAAAXti0nX57Naw8rOktUVPxyx0zUOrSVZvm5cocQIYLEhddzmPXEy WkQQIqNsZJ7g+yfTYmyHfxf6LOc85FX3T+/TRmdOBT7D X-Google-Smtp-Source: APXvYqw+OZV+jbTcMM4Uc9KZBDqfJAmxFoPAu+hYQhvKfkPreyoXS7BLEvg/+wPix1FCscqLpIQNN01AOF1KjyubK+8= X-Received: by 2002:a5d:9c4b:: with SMTP id 11mr7240806iof.120.1571388866234; Fri, 18 Oct 2019 01:54:26 -0700 (PDT) MIME-Version: 1.0 References: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net> In-Reply-To: Date: Fri, 18 Oct 2019 09:54:15 +0100 Message-ID: To: PHP Internals Content-Type: multipart/alternative; boundary="0000000000002d0db905952b7b7e" X-Envelope-From: Subject: Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through? From: rowan.collins@gmail.com (Rowan Tommins) --0000000000002d0db905952b7b7e Content-Type: text/plain; charset="UTF-8" Hi Bishop, I'm not the proposer, but would like to answer your questions anyway. On Fri, 18 Oct 2019 at 04:14, Bishop Bettini wrote: > Do you envision this token accepting an optional argument, as break does, > to fall-through multiple nesting levels? Eg: > > $x = $y = $z = 1; > switch ($x) { > case 1: > switch ($y) { > case 1: > switch ($z) { > case 1: fallthrough 3; > case 2: echo 'z2'; > } > } > break; > case 2: echo 'x2'; break; > } > ?> > I think we should keep it simple - we can always add more features later if a real need reveals itself. I note that the Go version linked to explicitly forbids the use of "fallthrough" in a conditional, and a multi-level fallthrough is effectively the same thing: the control flow in your example is something like if ( $y==1 && $z == 1 ) { fallthrough; } else { break; } I would have thought that by the time you've got nested switch statements with conditional fallthrough on multiple levels, the code is going to be very hard to reason about, so unless there's a key use case, I'd leave the complexity out of the language. There might be use cases for single-level conditional fallthrough, but I'd lean towards defining it as Go has: as a marker at the end of the case block only. By far the most common use of it I've seen is like Mike's: case x: additional pre-processing fallthrough case y: shared processing break > What do you envision the result of indicating fall-through to no subsequent > case? Eg: > > switch ($x) { > case 1: fallthrough; > } > I think it would be perfectly fine for this to do nothing. Currently you can write both switch ($x) { case 1: } and switch ($x) { case 1: break; } In general, I really like this idea; I've always wished switch worked this way. Regards, -- Rowan Tommins [IMSoP] --0000000000002d0db905952b7b7e--