Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120536
Message-ID: <96a69724-32d4-a3d6-d543-3020a90360db@gmail.com>
Date: Tue, 6 Jun 2023 20:20:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Content-Language: en-US
To: Christian Schneider <cschneid@cschneid.com>,
 PHP internals <internals@lists.php.net>
References: <646e0eee-b9e4-58bf-d118-3e5c7fa2ae52@gmail.com>
 <A18F4C9D-F038-41DE-A8FB-373D366E3C0D@cschneid.com>
In-Reply-To: <A18F4C9D-F038-41DE-A8FB-373D366E3C0D@cschneid.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] mb_str_pad
From: dossche.niels@gmail.com (Niels Dossche)

Hi Christian

On 06/06/2023 09:12, Christian Schneider wrote:
> Am 05.06.2023 um 19:59 schrieb Niels Dossche <dossche.niels@gmail.com>:
>> I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3.
>> RFC link: https://wiki.php.net/rfc/mb_str_pad
> 
> I voted "No" because I think it should be grapheme_str_pad instead and I'd like to avoid having both the mb_ and grapheme_ versions which unnecessarily confuses users.
> 
> I guess I should have spoken up before but I couldn't think of a use case for padding characters instead of graphemes. Or am I missing something?
> 
> - Chris
> 

Thanks for explaining, I appreciate that.

String padding is naturally often associated with display. The use-cases I had in mind are rather more related to data formats, protocols and/or standards. Although a lot of users who hand-rolled their own mb_str_pad misuse it for display purposes, there are use-cases that do indeed use it for the purposes I described above. Some random examples I found using GH code search:
* https://github.com/WPPlugins/estonian-banklinks-for-woocommerce/blob/5f97891cfb43d9bde6017243998a3ab424f43b93/includes/gateways/class-wc-banklink-estcard-gateway.php#L139
* https://github.com/ExaByt3s/fodyo/blob/eefdec7da76c820e90987b32baf2aef5ea8d6ca2/bitrix/modules/sale/lib/tradingplatform/vk/feed/data/converters/product.php#L179
* https://github.com/mbence/csaladsegito/blob/20e639b1865ac2ba6be8fc64f69ba9e6f474ef0f/src/JCSGYK/AdminBundle/Services/ClosingService.php#L381

I heard the grapheme argument two times before, one time on the list and one time on Reddit.
I do think it's primarily a documentation problem. One problem may be though that a non-negligible number of users probably don't read documentation. The fact that this comes up again gives me a little bit of fear whether the function would cause confusion. So I'm keeping my ears open for concerns.

For visual purposes I'm also not sure if a grapheme variant would fully suffice, as it would also require the grapheme to be fixed width. But that's another issue of course.


Kind regards
Niels