Just a +1 from my side. Looks good, useful and I've definitely caught myself skipping the strtolower out of laziness and "it'll probably be fine" in the past
When str_contains() was added, a case-insensitive version was deliberately omitted in favor of "just use strtolower() yourself." Have you gone back to see the arguments for that to determine if they're still relevant?
(I don't recall the details; I think one of them was function count explosion, but I think there were more.)
When str_contains() was added, a case-insensitive version was deliberately omitted in favor of "just use strtolower() yourself." Have you gone back to see the arguments for that to determine if they're still relevant?
(I don't recall the details; I think one of them was function count explosion, but I think there were more.)
--Larry Garfield
Hi
I have concerns from multibyte(Unicode) user.
As someone who relies on Unicode, I feel that it is not worth using
that function.
str_contains can matches binary, so this is benefit of many reason,
but str_icontains is only support ASCII.
This only benefits some regions.
When str_contains() was added, a case-insensitive version was deliberately omitted in favor of “just use strtolower() yourself.” Have you gone back to see the arguments for that to determine if they’re still relevant?
(I don’t recall the details; I think one of them was function count explosion, but I think there were more.)
–Larry Garfield
Thanks Larry.
Yes, I did spend time reading through the past discussions on both str_contains and the str_starts/end_with functions.
I think initial RFCs failed because (a) people felt that the functions didn’t necessarily bring a whole heap of functionality above userland code and (b) the debate about whether case-insensitive versions should be included.
Now that these functions exist, it seems weird as a PHP user that case-insensitive versions aren’t available to easily switch between.
Obviously we have the UTF-8 question that I’ve detailed, but I’m hoping adding this will solve a tiny issue where people expect this function to exist, but it doesn’t.
When str_contains() was added, a case-insensitive version was deliberately omitted in favor of “just use strtolower() yourself.” Have you gone back to see the arguments for that to determine if they’re still relevant?
(I don’t recall the details; I think one of them was function count explosion, but I think there were more.)
–Larry Garfield
Hi
I have concerns from multibyte(Unicode) user.
As someone who relies on Unicode, I feel that it is not worth using
that function.
str_contains can matches binary, so this is benefit of many reason,
but str_icontains is only support ASCII.
This only benefits some regions.
Thanks for your message.
I totally appreciate the multibyte issue here. I’ve detailed about it in the RFC.
This function is there just to help those that expect it to be available as parity to strpos, strstr that have ASCII case-folding case-insensitive versions available.
When str_contains() was added, a case-insensitive version was deliberately omitted in favor of "just use strtolower() yourself." Have you gone back to see the arguments for that to determine if they're still relevant?
(I don't recall the details; I think one of them was function count explosion, but I think there were more.)
--Larry Garfield
Thanks Larry.
Yes, I did spend time reading through the past discussions on both
str_contains and the str_starts/end_with functions.
I think initial RFCs failed because (a) people felt that the functions
didn't necessarily bring a whole heap of functionality above userland
code and (b) the debate about whether case-insensitive versions should
be included.
Now that these functions exist, it seems weird as a PHP user that
case-insensitive versions aren't available to easily switch between.
Obviously we have the UTF-8 question that I've detailed, but I'm hoping
adding this will solve a tiny issue where people expect this function
to exist, but it doesn't.
Adam
A discussion of that, and why you think the new position outweighs the original decision, should be included in the RFC.
(At the moment I'm undecided; yeah it's an easy enough utility to add, but the UTF-8 issue is real, and one could easily argue that it's stripos() that's wrong, because it's misleading as it only works on ASCII.)
The ideal answer would be Derick's built-in String object RFC, which I don't think has been touched in a while, sadly...
When str_contains() was added, a case-insensitive version was deliberately omitted in favor of "just use strtolower() yourself." Have you gone back to see the arguments for that to determine if they're still relevant?
(I don't recall the details; I think one of them was function count explosion, but I think there were more.)
--Larry Garfield
Thanks Larry.
Yes, I did spend time reading through the past discussions on both
str_contains and the str_starts/end_with functions.
I think initial RFCs failed because (a) people felt that the functions
didn't necessarily bring a whole heap of functionality above userland
code and (b) the debate about whether case-insensitive versions should
be included.
Now that these functions exist, it seems weird as a PHP user that
case-insensitive versions aren't available to easily switch between.
Obviously we have the UTF-8 question that I've detailed, but I'm hoping
adding this will solve a tiny issue where people expect this function
to exist, but it doesn't.
Adam
A discussion of that, and why you think the new position outweighs the original decision, should be included in the RFC.
(At the moment I'm undecided; yeah it's an easy enough utility to add, but the UTF-8 issue is real, and one could easily argue that it's stripos() that's wrong, because it's misleading as it only works on ASCII.)
The ideal answer would be Derick's built-in String object RFC, which I don't think has been touched in a while, sadly...
--Larry Garfield
That lives here, and ought to work fine as an extension for PHP 8.3+:
I’ll likely put this to a vote today/tomorrow as most issues have been discussed, and hopefully people can now have a balanced view about whether it’s worth including.
Thanks for all the feedback, really appreciate it.