Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105840 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99998 invoked from network); 5 Jun 2019 00:06:03 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 5 Jun 2019 00:06:03 -0000 To: internals@lists.php.net References: <20190603225238.080CC4F4064@mail.apserver.co.uk> <9e4e2ca4-a4af-927b-ff77-e2962dd4ac31@allenjb.me.uk> Date: Tue, 4 Jun 2019 22:17:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <9e4e2ca4-a4af-927b-ff77-e2962dd4ac31@allenjb.me.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Posted-By: 94.1.167.52 Subject: Re: [PHP-DEV] Re: PHP RFC: Nullsafe Calls From: markyr@gmail.com (Mark Randall) Message-ID: On 04/06/2019 20:05, AllenJB wrote: > Common use cases I can think of would be parameters in a method call, > which with null safe calls would be: >   $m->n($x?->y()?->z()); > AllenJB You bring up many good points about the (extremely hastily) composed syntax suggestion for short catch blocks, and their resolution is probably best left for a different discussion. It is an attempt to work around the somewhat built-in flaw in using nulls for such operations, mainly that null itself can often be a perfectly legitimate return value from the last link of the chain, and I believe being able to tell the difference would have at least some useful applications. Clearly there's ways around that using the current, more verbose method, but it would be nice if a way could be found so that this potential ambiguity wasn't there in the first place if this new mechanism is added. Mark Randall