Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101005 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76828 invoked from network); 1 Nov 2017 01:36:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Nov 2017 01:36:44 -0000 X-Host-Fingerprint: 95.148.70.12 unknown Received: from [95.148.70.12] ([95.148.70.12:1026] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B8/36-07742-B2529F95 for ; Tue, 31 Oct 2017 20:36:44 -0500 Message-ID: To: internals@lists.php.net References: Date: Wed, 1 Nov 2017 01:36:40 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 95.148.70.12 Subject: Re: [PHP-DEV] RFC - Array Of for PHP 7 From: ajf@ajf.me (Andrea Faulds) Hi Levi, Levi Morrison wrote: > My thoughts on the RFC: > > - The syntax `typename[]` is a poor. Consider how nullability might > bind `?int[]`. Is that `(?int)[]` or `?(int[])` ? Here are some > variants that do not have this issue: > [?int] and ?[int] > array and ?array Thank you for bringing this up. The introduction of nullables means that the type[] syntax is problematic and should probably be avoided now. As you say, there is an issue of ambiguity as to whether it would be interpreted as (?int)[] or ?(int[]). Unfortunately, both of these are reasonable interpretations and might be desired. So if we use that syntax, we'd have to add brackets. It would be simpler and prevent any misunderstandings if we use a syntax that is unambiguous in the first place. Personally I might like generics-esque angular brackets, but a problem there is that << and >> are operators with their own tokens, so supporting nested arrays (array>) would require some sort of lexer hack. > - Our current infrastructure requires us to check every element of > the array for conformance. While undesirable I believe this can be > optimized away in the future if we care enough, and therefore not a > show-stopper. > Something I've thought about but not gotten round to implementing is a typed array value. That is, you could write `$x = array(1, 2, 3);` and `$x` would contain a typed array that would enforce the types of values added to it. This feels like a cleaner solution, but it introduces a new issue: does an array type declaration require an array value, or will it implicitly cast from vanilla array? Thanks. -- Andrea Faulds https://ajf.me/