Hi Ben, > I don’t think changing the name changes my concern, but as Tyson > pointed out: > > > These idiosyncrasies of php and unintuitive behaviors existed prior > > to this RFC. > > I’m generally +1 on this RFC, but as I think about it, maybe there is a > problem with the name. If we choose to introduce a pure list construct > at some point, then `is_list()` may cause confusion (or maybe it won’t, > if it can be made to return `true` for a zero-indexed, standard PHP > array *and* a `list`, whatever that might look like in the language).
For the possibility of `list` being added to the language: The syntax conflict with `list($a) = ...` may cause issues with supporting it in the parser, and confuse people learning the language, but I can still see it as possible since the parser conflict also means that it wouldn't conflict with existing names (if that were fixed). The fact that my RFC is also using "list" to refer to sequential arrays starting with 0 may encourage that name over vec in the future, in combination with SplDoublyLinkedList already existing. - I guess `list[$a, $b]` may be usable as shorthand for list creation but that's out of the scope of this rfc So the naming's definitely a potential concern. My earlier idea of `is_array_list()` or `is_array_a_list()` may help avoid that ambiguity if that's a concern. I'd still prefer short terms for common language concepts - zero_indexed isn't a commonly used phrase Cheers, Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
