On 26/03/2022 22:22, Rowan Tommins wrote:
Maybe I'm trying to be "too helpful" there. Should we just use the
generic deprecation message, and let people look up the in-depth
explanation in the manual?
I've dropped the custom deprecation message from the proposal, as
there's just not room
On 24/03/2022 11:19, Rowan Tommins wrote:
I have one issue with the wording in the RFC: While “Function
utf8_encode is deprecated; check usage is correct and consider
mb_convert_encoding or other replacement.” suggests to replace it,
the part about checking the usage implies that if someone is
On 24/03/2022 09:52, Christian Schneider wrote:
If these functions were proposed today, under better names but the same feature
set, I don't think mbstring being optional would be accepted as reasoning for
adding them to core. So the only reason to keep them is if they're widely (and
Am 24.03.2022 um 10:32 schrieb Rowan Tommins :
> On 23/03/2022 23:39, Juliette Reinders Folmer wrote:
>>
>> While I agree the functions are often used incorrectly, what worries me
>> about this RFC is that the only viable alternatives for these functions are
>> in two optional extensions, which
On 21.02.2022 at 18:35, Rowan Tommins wrote:
> On 21/02/2022 16:29, Alain D D Williams wrote:
>
>> Looking at the description of grapheme_strlen() I note that it can
>> return null.
>> However it does not say why>
> Huh, that feels like a bug to me, since it can also return false, which
> is the
On 21/02/2022 16:29, Alain D D Williams wrote:
Looking at the description of grapheme_strlen() I note that it can return null.
However it does not say why.
Huh, that feels like a bug to me, since it can also return false, which
is the more standard way of indicating failure.
The obvious
On Mon, Feb 21, 2022 at 03:52:57PM +, Craig Francis wrote:
> I would personally encourage everyone to have ext/intl installed and use
> > grapheme_strlen() instead of mb_strlen(), because knowing whether a
> > particular instance of the string "Nguyễn" is written with 6, 7, or 8
> > code
On 21.02.2022 at 16:52, Craig Francis wrote:
> On Mon, 21 Feb 2022 at 09:09, Rowan Tommins wrote:
>
>> Making the extension always available (impossible to compile without it)
>> is a potential option, and I think has been suggested before; I'm not
>> sure of the exact pros and cons.
>>
>
>
On Mon, 21 Feb 2022 at 09:09, Rowan Tommins wrote:
> Making the extension always available (impossible to compile without it)
> is a potential option, and I think has been suggested before; I'm not
> sure of the exact pros and cons.
>
[...]
I would personally encourage everyone to have
On 20/02/2022 23:54, Craig Francis wrote:
I'm just wondering, and this would not be necessary... considering how
most systems need to deal with UTF-8 data today, could an argument be
made for enabling etc/mbstring by default?
I'm fairly sure Ubuntu and CentOS need to install the package
On Sun, 20 Feb 2022 at 23:12, Rowan Tommins wrote:
> I don't have hard facts to back it up, but my impression is that
> ext/mbstring is quite commonly installed, and required by apps and
> libraries. Unlike the other two, it has no system dependencies, because
> the implementation is entirely in
On 20/02/2022 21:24, Craig Francis wrote:
Only query I have is about the availability of different functions...
not sure why, but the documentation says these are provided by the
"xml" extension, even though it looks like they are in
`./standard/string.c` (your pull request seems to correct
On Sun, 20 Feb 2022 at 18:55, Rowan Tommins wrote:
> I would like to open discussion on an RFC to deprecate and later remove
> the functions utf8_encode() and utf8_decode()
>
> https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
>
Thanks Rowan.
Whenever I see these functions being
Good $daypart everybody,
I would like to open discussion on an RFC to deprecate and later remove
the functions utf8_encode() and utf8_decode()
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
This is not a straight-forward decision, because these functions are not
actually
14 matches
Mail list logo
