On Monday 30 March 2026 11:46:11 (+02:00), LamentXU wrote:
> Thank you for ideas! AFAIK here are my thoughts on this
>
>
> Now I realized the point that, those trim functions are not supposed to
be used to remove whitespaces in strings, which solves my main concern that
NUL is not a 'space' character.
>
>
>
> On top of that, we still have security concerns (and more) for this
change, **and therefore I would like to withdraw this RFC.**
>
>
> Moreover, the proposed new function 'trim_whitespace()' seems to be more
reasonable for people to use to strip whitespaces instead of casually using
the trim family, which would obviously be a better solution in this case.
>
>
> Thank you for your attention and suggestions!
Thank you!
And yes, the security thing is the blocker on NUL, but if trim_space() idea
clicked, and given your interest in topic and the bit precision you've
shown, may I ask you if you have some interest in implementing it? Take
your time for the answer, just sharing that I think your spotting of the
"missing \f" shows attention to detail, and this is certainly both required
and trim-able when there is need to delve into UTF-8 for the new idea (I
have borrowed it from Golang as you wrote in both of your suggestions we
should do more language comparison, which also was very insightful for me,
so thank you for that, too!)
Apart from that, what are your thoughts about/for a constant preserving the
original characters so in case the first change poses a problem for
language users, they can find it and go on with it? -- That was a question
raised shortly with the first RFC, in how far the change will introduce
problems (albeit no one wants this), but because \f is that old it is hard
to answer that question technically I think (even if we scan tons of
code-bases for usages), so probably my thinking was that we should not
leave users alone in case it is an issue for them and with a standard
constant Tim or so can do some compiler string magic probably even. But
that might be a bit my fantasy, we would first need to have a constant(?)
before it could be discussed with him/other PHP compiler people. I'm open
for other ideas/thoughts as well, the constant was a bit of an
after-thought when writing, and it's good when you stay in the driver seat,
I can only try to give some explanation when I see it or you ask and offer
help with explorative testing. You own it, you make it out!
Thank you again!
-- hakre