New function mb_str_pad (multibyte str_pad)

[aetonsi]

Description

Hello,

I'd like to propose a new function. Amidst all of the mb_*** versions of the string functions, i noticed that one is missing: str_pad.
Something that would allow to do this:

mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_RIGHT);
mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_LEFT);
mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_BOTH);

and get this

▶▶❤❓❇❤
❤❓❇❤▶▶
❤❓▶▶❤❓

It could be as simple as this:

function mb_str_pad(
    string $string,
    int $length,
    string $pad_string = " ",
    int $pad_type = STR_PAD_RIGHT,
    string|null $encoding = null
) {
    $padding = '';
    $paddingLength = $length - mb_strlen($string, $encoding);
    while (($l = mb_strlen($padding, $encoding)) < $paddingLength) {
        // build padding string 1 $pad_string at a time until the desired $paddingLength is reached
        $padding .= mb_substr($pad_string, 0, $paddingLength - $l, $encoding);
    }
    return match ($pad_type) {
        STR_PAD_RIGHT => $string . $padding,
        STR_PAD_LEFT => $padding . $string,
        STR_PAD_BOTH =>
        mb_substr($padding, 0, ceil(mb_strlen($padding, $encoding) / 2)) .
            $string .
            mb_substr($padding, 0, floor(mb_strlen($padding, $encoding) / 2)),
    };
}

...obviously this is just an example, it's not optimized, it doesn't consider errors, etc

---

Have a nice day

[cmb69]

Hmm, might make sense to have this, but a variant working on grapheme clusters might actually be more handy. The latter would probably need to go into ext/intl, though, since there are already the grapheme_* functions, but ext/mbstring doesn't now anything about these.

This might also fit in the proposed Text class. /cc @derickr

/cc @alexdowad

[alexdowad]

Either way is fine for me. If there is popular demand for the feature in mbstring, I don't mind to add it there. I would leave it to the people who need the feature to go through the RFC process.

[cmb69]

Requiring the RFC process makes sense to me.

[aetonsi]

@alexdowad i don't think there is or will ever be popular demand for this feature in any case... it's not a very common use case, i think. I mainly proposed it for consistency, since it seems a simple algorithm to me (i could be absolutely wrong, i just wrote that example function in a few minutes)... obviously the actual implementation, for anyone unfamiliar with the php source or even more so the languages it's written in, would be pretty difficult, and very time consuming (unluckily i don't have enought time to learn about the php source, and C, at the moment). All of this to ask, could i (try to) go through the RFC process indicating you, sir, as a possible implementer? ("try" because even the RFC process itself seems pretty cumbersome and time consuming so i don't know when i'll be able to do it, but i want to do it)

[alexdowad]

@aetonsi Well, it's up to you what you want to do. If you do feel strongly enough that mb_str_pad would be useful for yourself and others, you are welcome to put me down as implementer on the RFC. If you don't want to go through that process, that is also fine.

[github-actions]

There has not been any recent activity in this feature request. It will automatically be closed in 14 days if no further action is taken. Please see https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea to understand why we auto-close stale feature requests.

[aetonsi]

ok i will try to do this RFC thing in the weekend, i hope i don't mess up...

if i have questions about the RFC process itself, where can i ask them?

[damianwadley]

@aetonsi The RFC process that cmb69 linked earlier should cover everything. You can also take a look at how some of the current RFCs are going and being discussed, to get a better idea of how it goes. If you have a simple question then you can ask here...

...but it's really fairly simple to start with: spend some time thinking through your idea, figure out what it's good at and what it could use improvement on, consider alternate viewpoints that others might have... When you're ready, join the internals mailing list, present your idea, and start the discussion. Writing up an actual RFC document can wait until after that.