On Tue, 14 Nov 2023 at 02:08, David Gebler <davidgeb...@gmail.com> wrote: > > On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings <andr...@dqxtech.net> > wrote: > > > So to me, this alone is an argument to implement this natively. > > The other argument is that it is kind of sad how the current functions > > don't behave as one would expect. > > > I'd expect there to be a larger and proportionately increasing performance > difference between array_diff versus array_udiff with callback or a > userland array_diff_strict function the larger the datasets you feed in. > But I'm not sure how common either the use case of diffing arrays of 25,000 > or 250,000 elements might be, or needing this comparison to be strict > equality. I suspect the use case where both these conditions apply is very > rare.
The idea is to use the new functions in general-purpose algorithms without worrying about type coercion or scaling. > > But if you want to create an RFC, please go for it. You could add an extra > parameter to these functions after the input arrays, which was a flag for > strict comparison. Whether such a thing with a default value of non-strict > (so not BC breaking) would be considered preferable to new global > functions, I'm not sure. I'd probably go with new functions but maybe > someone else will weigh in with their thoughts. The extra parameter does not really work for array_diff() or array_intersect(), because these have variadic parameters. Or at least it would not be "clean". Technically we could just check if the last parameter is an array or not, and if not, we use it as a control flag. But I don't really like it that much, I prefer clean signatures. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
