Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107620
To: PHP internals <internals@lists.php.net>
References: <CAP=w73VJ6pxstVzyfFkOp=esX7ne-LosWP1Eb8Ac0u-JeROPRA@mail.gmail.com>
 <C86ED976-5E52-428E-A824-0429601AB3FE@newclarity.net>
 <CAP=w73VNggn6yXnueYwfUS0EbCB6eFMGTy72DRiiTTEWdOVhMQ@mail.gmail.com>
 <3D85D31D-5DDD-42AA-B465-6ADBE72D952A@newclarity.net>
 <CAP=w73U-KF2WF6oaev2tKy6oP+2xJ+JQox8zHdLOeZufj9ZVeQ@mail.gmail.com>
 <9A432898-EB7A-45C9-9C6F-AE6392B9B5C3@newclarity.net>
 <CALKiJKrHC-K-=bOj2PHq54qJzioBnP=PnDYvtD+k=gVFCwG3=Q@mail.gmail.com>
 <10B38D5F-C2BF-4657-BC58-B302C096A18F@newclarity.net>
Message-ID: <5f2f13a9-7500-9c5c-7a2a-dfc883b2907b@gmail.com>
Date: Mon, 21 Oct 2019 23:02:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <10B38D5F-C2BF-4657-BC58-B302C096A18F@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] 'switch-expression' and the 'type guard' unary operator
 demo
From: rowan.collins@gmail.com (Rowan Tommins)

On 21/10/2019 21:18, Mike Schinkel wrote:
>
>     But to follow up to clarify what I was thinking consider the
>     following/ (hypothetical) /PHP syntax. Note that the return value
>     has two comma separated values, and the assignment can accept
>     those multiple values into two comma separated variables in the
>     assignment:
>
>
>         function read_file(string $filepath):string,PHP\Error {
>         $content = file_get_contents( $filepath ); $error = false ===
>         $content ? new PHP\Error( "failed to open '%s'", $filepath ) :
>         null; return $content, $error; }$content, $err= read_file(
>         __DIR__ . '/myfile.txt' ); if (!is_null( $err ) ) {
>         error_log($err->message); }
>

Ah, I see. Yes, multiple return values would be nice sometimes.

Note that you can get a lot closer to this in current versions of PHP 
than your example, because you can use the [...] syntax for both 
creating and destructuring arrays:

         function read_file(string $filepath):array {
            $content = file_get_contents( $filepath );
            $error = false === $content
               ? new PHP\Error( "failed to open '%s'", $filepath )
               : null;
            return [ $content, $error ];
         }

         [ $content, $err ] = read_file( __DIR__ . '/myfile.txt' );
         if (!is_null( $err ) ) {
            error_log($err->message);
         }


>     With the first example PHP could type check at load time vs.
>     having to wait for coverage of this code at runtime, and `:array`
>     type hint in the latter is not as good as the `:string, PHP\Error`
>     type hint of the former.
>

The ability to typehint multiple return values like that would be indeed 
be useful, but I'm not sure it would need to reserve that syntax. One 
way it could be achieved is using a "tuple" declaration, like in Hack: 
https://docs.hhvm.com/hack/built-in-types/tuples

In general, grouping things with commas and no parentheses is always 
going to *look* ambiguous IMO, even if you can limit where it's used to 
not be *technically* ambiguous.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]