Re: [PHP-DEV] Typed array properties V2
> On Jan 19, 2020, at 8:42 PM, John Bafford wrote: > As a thought, perhaps the syntax '[Type]' for an array of Type. That way, you > could write ?[int], or [?int], or even ?[?int] and there would be no > ambiguity, and no need for parentheses since the array brackets would serve > that purpose. That syntax was what someone suggested on the prior discussion. I personally dislike it because I have used PHPDoc syntax of `type[]` for so long and would rather see us stick with that. But if I'm honest about it, debate over syntax is probably just bikeshedding at this point. The more important question IMO is, can we actually implement typed arrays to enough voter's satisfaction and w/o a significant performance penalty? -Mike
Re: [PHP-DEV] Typed array properties V2
> On Jan 19, 2020, at 19:53, Mike Schinkel wrote: > > P.S. There was also the mention by Levi Morrison that the type[] syntax was > a poor one because of ambiguity between (?int)[] or ?(int[]). I would argue > that the latter would likely occur orders of magnitude more often than the > former, so I would argue that ?int[] should interpret as ?(int[]), and if > they want (?int)[] then the developer should use parentheses. As a thought, perhaps the syntax '[Type]' for an array of Type. That way, you could write ?[int], or [?int], or even ?[?int] and there would be no ambiguity, and no need for parentheses since the array brackets would serve that purpose. If we also wanted to allow typing array keys, this syntax could be extended to [string : Type] and [int: Type], and it would continue to remain unambiguous, even with nested arrays, and with using a more similar syntax than the docblock syntax array. (It might also be reasonable to support both variants as aliases of each other.) Both of these are the syntax Swift uses for arrays and dictionaries, so the syntax has precedence from another language. Swift also supports both syntaxes as described above ([KeyType : ValueType] is exactly the same as Dictionary), but the shorter bracket syntax is preferred for readability. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed array properties V2
Hi Nikita, > On Jan 18, 2020, at 5:05 AM, Nikita Popov wrote: > Did you read through the previous discussions on this topic? > https://externals.io/message/100946 in particular comes to mind. Thanks for this link. It was very insightful. > The primary concern about the previous typed array proposal was the O(n) > cost of type checks, which required iterating over the whole array and > checking the type of individual elements. Any new proposal in this area > *must* address this concern. Agreed. > As far as I know, the only viable way to do that is to make the array > intrinsically typed, which means that types are validated when elements are > inserted into the array, not when it is passed across a function boundary. > In other words, array generics. Reading the prior discussion, there appeared to be several other potential approaches, but none were followed to a conclusion. Of course it devolved into bikeshedding, but I digress... One approach mentioned by Andrea Faulds was to extend the hashtable (ref: your article[1]) and count types as assigned just like we currently count references. So a 10,240 element array of ints could have an internal tracker showing that the array contains type(s): ['int' => 10240]. Append a string value to the array and then the types would be ['int' => 10240, 'string' => 1]. Mark Randall mentioned that this would not work if the array contained references, but no one discussed the potential of simply disallowing arrays with references at compile time when the arrays are typehinted, which seems like it could solve the proverbial 80/20 scenario. Need references in arrays? Don't typehint them. Also, Rowan Collins mentioned that checks in Go can be disabled for runtime checking; maybe we could support an option that disables said checking so that production sites could run w/o checks but we could run checks in development, testing and staging. We could also have an option to disable checking of array types above a given size of array, maybe defaulting to 1024? Clearly both of these would be no worse than what we have today. I think this could add a major improvement to PHP all without having to finalize the design and implementation of generics, no? Are none of these viable options? I am asking that as a legitimate question — as I am not (yet) a PHP internals developer — and not just assuming they are viable options. -Mike [1] https://nikic.github.io/2012/03/28/Understanding-PHPs-internal-array-implementation.html P.S. There was also the mention by Levi Morrison that the type[] syntax was a poor one because of ambiguity between (?int)[] or ?(int[]). I would argue that the latter would likely occur orders of magnitude more often than the former, so I would argue that ?int[] should interpret as ?(int[]), and if they want (?int)[] then the developer should use parentheses. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warn when declaring required parameter after optional one
On Fri, Jan 17, 2020 at 11:59 AM Nikita Popov wrote:
>> I've created https://github.com/php/php-src/pull/5067 to make code like
>>function test($foo = null, $bar) {}
>> throw a warning
>
> I was interested in seeing how prevalent this pattern, is, so I ran
> some analysis on the top 2k composer packages. I found 527 signatures
> that would throw a deprecation warning with this change. Of these 187
> are potentially used as "poor man's nullable types" (the optional
> argument has both a type and a null default), while the other 340 are
> definite bugs.
Given that most of these usages are definite bugs, I'm in favor of
deprecating this in PHP 8 and making it a compile error in PHP 9. This
should provide plenty of time for codebases to migrate to the simpler
nullable types syntax for the minority of usages that aren't bugs.
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Warn when declaring required parameter after optional one
Hi Nikita, Nikita Popov wrote: Since nullable types have been available since PHP 7.1, having a required parameter after an optional one is increasingly likely a bug rather than an intentional workaround, so I think it would be good to throw a warning for this case. Wouldn't it be trivial to special-case `= NULL` here to not cause a warning, or to cause an E_NOTICE instead of an E_WARNING? That would make this less annoying for old code. I don't know whether I think this worth doing or not, I just want to point out the possibility. Thanks, Andrea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
