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<?int> and ?array<int>
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<array<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<int>(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<int> type declaration require an array<int> value, or will it implicitly cast from vanilla array?
Thanks. -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
