Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109593
To: Ilija Tovilo <tovilo.ilija@gmail.com>, php internals
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [DISCUSSION] Match expression
Thread-Index: AQHWEF+nZG5U35iOAE6gUQQi9rmkvqh1PESG
Date: Sun, 12 Apr 2020 09:56:29 +0000
Message-ID:
 <VI1PR08MB2813513D859F91441C020848B8DC0@VI1PR08MB2813.eurprd08.prod.outlook.com>
References:
 <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
In-Reply-To:
 <CAPyj-LDfdATXFD+dc5AY9EqWWxgf8LP1joD2fzvm==1gUoN35A@mail.gmail.com>
Accept-Language: es-ES, en-US
Content-Language: es-ES
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [n4b8KSKC4S/nLQ95cY4IyESXPwo3pULZ]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 2d5f020b-456f-45be-f147-08d7dec7c610
x-ms-traffictypediagnostic: VI1EUR04HT046:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 C/M/N5iH42Er2UPYu1UFl54cmiMDjGJjMRbnji4E2A0X3HD3oJi4bqCRZ+Tq4OehJ9Dz/PptFracHPt2RjVLDJ0S6sfLQNf3DvzbpyWuOoN1Q9lc0WAz6NeDpN86OtA6bYXrPzY/IokJgcnK1IxtrUttfLhtPj99njDyx1e5on8YuNrIJMp9u/CKwFlVTxeZvEIfE2lWCi3yC7MuwPEGzQIc2DjwlXa3/INg4Jfqk+s=
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB2813.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 spK/riCL9LR1PRtoH60UWMXINVWe92i4sg1NIU7KpYMvXs2zsKf9/t0hSIhNPlfmCbk6p3H054fToCJpoxIpTKmfeZ7C1mUR3VBMtO3BFQaUaDFsCoa1np2+DhZdn+0CpdrSB2eAjhZiu9gkZBcCLA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
	boundary="_000_VI1PR08MB2813513D859F91441C020848B8DC0VI1PR08MB2813eurp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d5f020b-456f-45be-f147-08d7dec7c610
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2020 09:56:29.8811
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR04HT046
Subject: Re: [PHP-DEV] [DISCUSSION] Match expression
From: txigreman@hotmail.com (=?Windows-1252?Q?Iv=E1n_Arias?=)

--_000_VI1PR08MB2813513D859F91441C020848B8DC0VI1PR08MB2813eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

> Hi internals
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression
>
> Due to the feedback I decided to take the RFC in a slightly different
> direction. The main objections were:
>
> 1. It didn't behave like the traditional switch so it shouldn't use
> the switch keyword
> 2. It didn't fix type coercion
> 3. The RFC was poorly structured
>
> In hindsight I understand why I had a hard time writing the RFC. I
> tried making a case against the switch statement while really not
> addressing the switch statement at all. The new RFC proposes a match
> expression that fixes all the objections raised against the switch
> statement. Additionally, match arms can now contain statement lists
> which allows you to use the match expression anywhere the switch
> statement would have been used previously.
>
> While some people have suggested statement lists aren't necessary I
> don't think it makes sense to raise objections against the switch
> statement without offering an alternative.
>
> I also experimented with pattern matching but decided against it. The
> exact reason is described in the RFC.
>
> I'm now confident this is the right approach. I hope you will be
> happier with this proposal.
>
> Happy Easter!
Hello Ilija,

I really like much more this new approach. Only a pair of questions:

Would be posible for blocks to require a return statement instead of raisin=
g an error?

$y =3D match($x) {
    0 =3D> =91a=92,
    1 =3D> {
        foo();

        return 'b=92; // OK
    }
    2 =3D> {
        var();
    } // Error, return statement is required
}

Would be feasible for the fallthrought problem to use =93continue=94 when y=
ou really want to chain =93cases=94?

match ($x) {
    0 =3D> {
        // Only for 0
        continue; // Same as omitting a break in a traditional switch
    },
   1 =3D> {
       // Same for 0 and 1
    }
}

Regards,
Iv=E1n Arias.

--_000_VI1PR08MB2813513D859F91441C020848B8DC0VI1PR08MB2813eurp_--