[RFC] Allow specifying keys in list()

Hi Andrea I am writing you in private since I think this is rather out of scope. -----Ursprüngliche Nachricht-----

I agree with Pierre on this one. Using list for named parameters seems like a lot of overhead on the declaration side to me (writing the name of a parameter twice). IMO it should not require additional effort than writing a function/method today and it should be available for all functions/methods and not only for ones with special named-paramater-syntax. I think you should consider further (when thinking about using the new feature for named parameters) - how can you specify optional parameters? - how can you specify byRef parameters? - what happens if one does not provide all keys? Currently this: list($a, $b) = [1]; //only produces a Warning - are there differences between strict mode and none strict mode? e.g., what if the type of the key is different? - would it be possible to use a type for the key as well (as for the value indicated in your RFC)? - would you allow nested destructuring for parameters? - how would you reduce the overhead of creating an array which is then copied and passed to the function? IMO destructuring parameters and named parameters are two different things which could be combined. Something like this: function foo(SomeClass $class, list("x" => $x, "y" => $y) $point = ["x"=>0, "y"=>0], $flagA = true, $flagB = 1) { } foo($myClass, point: [1,2], flagB: 0); foo($myClass, flagB: 2); yet, IMO it would hamper readability (probably in many cases) and it would be better to do it inside the function. I understand destructuring parameters just as syntactic sugar and I would still expect that PhpDocumenter would indicate that my function requires an array. Otherwise the same feature would suddenly also be used to declare deep structured data structures and at this point I am not so sure whether auto conversion of keys play well together with strict mode. It would certainly be interesting from a type safety point of view that one can define very complex data structures and let PHP do the work for verification. Yet, it also opens a door to very ugly code (well... which also exists without the feature) -- sorry, drifting away from the topic. Some other points crossing my mind - how well does the feature interact with typed arrays (if they should be introduced at some point)? - how well does it interact with structural types (if they should be introduced at some point)? And now some points to the RFC: - I like the RFC in general - I am not really a fan of the naming "list" in general but I think it is appropriate to reuse the same syntax for this task. - one thing I am missing in the RFC is error handling. What happens if a key is not found? And there are surely other questions. I think you should include a section about error handling in the RFC. - I guess mixing number keys with string keys is possible, right? - are placeholders (something like list(_ , $a, _) = [1,2,3]) in your pipeline or do you think they make no sense in PHP? - already an idea how it would interact with pattern matching? Cheers, Robert

I would like it to be like, destructuring assignment, in ES6 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

Hi Leigh, Leigh wrote:

In fact I don't think extract() even works on object properties. list() works with any "variable" (in the isset() sense). I should really add some more examples to the RFC, so that it's more obvious that $this-> assignment is not the only thing this can or will be used for.

So far I haven't actually heard anyone say they thought it would behave like (1), which is making me think that allowing arbitrary expressions would be fine. It'd be unfortunate to lock them out, because constants can't contain objects, so now you wouldn't be able to use list() with SplObjectStorage and such, and that would be a shame. (2) is the only thing I was going to make it do anyway, (1) would mean list() functioning differently than it does at present.

Oh, yeah, it's unfortunate that what the RFC currently proposes makes using initial offsets not possible. :/ The main reason I ended up disallowing mixed keys was because it complicates implementation if you have a some value that must be computed at runtime as a key (some constants, a variable, etc.), because now we can't hard-code the indexes of the following values into the opcodes. We don't know at compile-time that it'll be 5, 6, 7, we know it'll be $x, *maybe* $x + 1 (if $x was an index, otherwise it'll be the previous index), *maybe* $x + 2, etc. The problem with disallowing mixed keys is it's inconsistent with the array literal syntax, and as you've demonstrated, it also is inconvenient for some use cases. As implemented, keyed list() is actually an entirely different parser branch from unkeyed list(). It's all a bit too arbitrary. I may just have to allow mixed keys after all, even if it does make implementation a pain. I could add an exception for a leading offset, but that would have to have its own special rules. Better to just do things properly.

I'm glad you like it!