On Tue, Jun 13, 2017 at 8:44 PM, Pedro Magalhães <m...@pmmaga.net> wrote:
> Hi internals, > > Based on the feedback on the original RFC targeting 7.2, I have now updated > the RFC to target version 8.0. Additionally, I changed the existing PR to > throw a E_DEPRECATED notice on the cases where this RFC will cause a BC > break when the change is implemented to ease the detection of such cases. > > I have closed the current vote (YES 14 - 16 NO) and opened a new one for > the revised RFC targeting the next major version. > > You can vote (again) at https://wiki.php.net/rfc/negative_array_index > until 28/6/2017 19:00 UTC. > > Regards, > Pedro > As this is a significant change to the RFC, I'd recommend moving it back to discussion first. Without some further evaluation, I am not sure whether throwing a deprecation from a low level hash API function like this is safe. The deprecation may be converted into an exception and it's not immediately clear that calling code will handle this correctly. In any case, even assuming this is safe, what is the expected behavior if the deprecation notice is converted into an exception? As the implementation stands right now, the element will still be inserted into the array. Is this intentional? ("We don't care" is also a valid answer -- it's an edge case.) It would also be nice to quickly check what the performance impact of this change is (a micro-benchmark on array appends should be enough). The patch adds a number of additional checks in a very hot code-path, which may or may not have a measurable impact. Regards, Nikita
