Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129785 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 56B2E1A00BC for ; Sun, 18 Jan 2026 20:11:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1768767065; bh=+ao5CiEfeBsHsaOajwsp4ZzA4TeXD9a7SfU0bZSYsmg=; h=References:In-Reply-To:From:Date:Subject:To:From; b=n4QD43jRnJe6Tmlbskr2r+XRQJsmw9chHBFj0lAG+WhxWpuLbDRp1Z9a3ZVIMhVMd pNFcIZQa8keMG/ePx+2UYTr96WSpnPDFkw4jvkwKN4JGfwJUgoZ3tIa4Xk3rBhjm// XLNpc2wpVq86XbIptrNvx4jKYg0vt3nMR5di0ivdARViDFB5+sFcPshE6G5zQ1jktE jROBOrX4+wFlwwoWs1Wi57y0VQvklIVPAwe92Yc18UhcrvcmjEeyqQpoNxs39nborB kjAgVETsjU0GXHm8RM5s1CcdvRTMdhvM3CTL+aKnyX2nCZH5dIpomX+wKjzQUs61It VJHKFVdXv01ow== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B7CB9180054 for ; Sun, 18 Jan 2026 20:11:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 18 Jan 2026 20:11:04 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-655af782859so4721583a12.2 for ; Sun, 18 Jan 2026 12:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768767058; x=1769371858; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=HHFagKsgPrDXY8EwWZFKLJ/20O0fjo/cXLDFg8xXVYs=; b=c3vC31/2+7d/ZBmHkqxmOiw9i9a/cVScN+s7ANOUHsln30YI5k3htUAFU/FapczCLE dZwuaUn7UAysKhW59CpDKoeEb3lgzM9txCRozCwZxOvgxRLYe98zNZsgdCqsrXAIC08E 5u3GMZqFGVMmsD6kjh5YMuGJPpazoVk7Op6etKrCX9JCtlQ6gfVVCe9WPGI0xNwgjdX7 Qs4Od0mn6x6AMK8ZA2mkSi4FBkP9U8s38ShHeauhXqNMb2ApEaKQpsLvJtD5bcvi0SuB jyNaSboSvtaDzkgIM9ab0beO4LrHWO0KsUcbxg9KmMIEBzBEHQR+bHposjuvLDHZL8up zoOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768767058; x=1769371858; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HHFagKsgPrDXY8EwWZFKLJ/20O0fjo/cXLDFg8xXVYs=; b=TGLP9w55hELBsIAUeFX8C9RtvZ8jRWn1RUiHspqzzILEJw+CRvpGooiDoJ6hlHePza 4huGaGSkrUNeiofvHM0Ho6Lv3OhTdjz10R2amoEJZLLmos3N3m2qhYefNOodtR9hhCX+ k2EbzdRamEHLixZwTJp6CXeIQPdaI5AU2YLb5pOhw7uwmvhff0r8aSi6p/nzFHhfCXEf JtE2IFxXRtILuy9aeUlyC4ItU95iMRjAXjMD5NZwkQ6y2ZRzP3oFSBPZS4HSaG4I5Jr7 SME9ULiqFTYbs0p9Acktddi3JzKtCGwlOHvzLw7UOBzcs328rMYyX9sSSkoqjhsQkYdT E91A== X-Gm-Message-State: AOJu0YxqOWQfWtks+cPxV7MYjsWQCUaPsrJQb7IMjDUnYEXe+jVeF5s+ wnOXs+1XRLsBWM8C2zGq6SeO5GRIll5BV3z3oPn4lZ3uhBx+EY2H3F8UnSgtm/bIMgXTKUYV7Xa /hQD39Skk20yWD710BJ3Pi+F/229G5dGBzg== X-Gm-Gg: AY/fxX4yAoAQQFlNhUp0/jE7Eu5ZFHXf14og+1r2S1QOQgV0Deud7iX39dJ0vcGeeDs SmWaAQRZ17usRIMQuW69I7zftbDR5YpJx2pLGOp4TLiIEvBtkccDq2TIjXSQ8gV1iufkLPRNp7C iKoFZhhZPxrr9+vzlJXEPgraQZKrc5QlaQJybMdKE/i+frA52kOuyV58s8wFMBSZTWIAlfGXtgD jYbofPhFnL7LTIvJFcGtyDcUYvMnfAEw9YrAtOb6nH+o1SN1SlzOTGqr87QGSH4wfZpvFOMwtJD ExF5VURjmhuvjP1S0Dm0lBexRo0m X-Received: by 2002:a05:6402:42c4:b0:64b:57d2:7ce4 with SMTP id 4fb4d7f45d1cf-65452bcc081mr6181602a12.27.1768767057718; Sun, 18 Jan 2026 12:10:57 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 19 Jan 2026 06:10:46 +1000 X-Gm-Features: AZwV_QiaLbG1BExInKVUE45rzsle0bBmmKMujusG7SPP4h6nR5aOYDQa0LsynN0 Message-ID: Subject: Re: [PHP-DEV] Proposal for functions that handle prefixes and suffixes To: PHP internals Content-Type: multipart/alternative; boundary="0000000000002a71800648af2c3e" From: mickmackusa@gmail.com (mickmackusa) --0000000000002a71800648af2c3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't recall ever needing to ensure prefixes or suffixes, but I have wanted to prepend or append a string to an array of strings. Maybe there is some demand for "ensuring" when working with phone numbers or product SKUs. I don't know. Whatever logic is required for a given scenario, does this need to be built into the core? I once asked about adding array_transpose() to the core, and the response boiled down to: PHP doesn't need a core function for every possible data manipulation. Topically, circa 2024-03-24, I proposed to modify substr_replace() which is a solid go-to for prepending, but not appending. (Subject: "Proposal: Make $offset of substr_replace null by default") This is because the offset parameter does not accept null. Food for thought. substr_replace( array|string $string, array|string $replace, array|int $offset, array|int|null $length =3D null ): string|array Contextual usages: - [Add prefix string to each value of a flat array][ https://stackoverflow.com/a/78210830/2943403] -[Fastest way to add a prefix to all array keys?][ https://stackoverflow.com/a/76196482/2943403] - [Regex to Add a postfix to each item of a PHP array][ https://stackoverflow.com/a/79083258/2943403] Mick On Sun, 18 Jan 2026, 21:30 Tim D=C3=BCsterhus, wrote: > Hi > > On 1/16/26 20:16, Barel wrote: > > Nevertheless, the idea is that in php code many times we have to deal > with > > prefixes or suffixes of strings, this comes up a lot when you are deali= ng > > with file names or urls. Some examples > > From the back of my mind I seem to remember that this was previously > proposed with similar use cases, since I can remember saying the same > I'm saying here before: > > Filenames and URLs are probably the worst possible use case for this > feature, since they are =E2=80=9Cstructured=E2=80=9D strings where naivel= y performing > string operations at best just results in garbage and at worst result in > security issues. > > > - If the domain includes a initial www part, remove it > > This just seems unsafe, since you are likely making assumptions about > URLs you don't own. > > > - If the filename includes the .png extension, remove it > > basename($filename, ".png"); > > > - If the URL does not include the http:// schema, add it > > Simply adding a prefix will break URLs that already have a scheme. Use > PHP 8.5's URI extension instead. > > > - If the URL is missing a trailing slash, add it > > - If the URL starts with http://, change it to https:// > > URI extension. > > > - If the filename ends in .jpeg, change it to .jpg > > Here you probably want to have more than one mapping (e.g. .htm to > .html), so you would probably use a combination of `pathinfo()` and a > lookup table. > > > function replace_prefix(string $source, string $prefix, string $replace= ): > > string > > function replace_suffix(string $source, string $suffix, string $replace= ): > > string > > > > Replace a prefix or suffix in a string it the string has it > > This parameter order is inconsistent with both str_replace and > preg_replace, which are likely the two closest existing functions we have= . > > Naming-wise these functions should definitely start with a > `str_(pre|suf)fix_` prefix for proper grouping and autocompletion. Thus: > > - str_prefix_add() > - str_prefix_remove() > - str_prefix_replace() > - str_suffix_add() > - str_suffix_remove() > - str_suffix_replace() > > See also the corresponding policy: > > https://github.com/php/policies/blob/main/coding-standards-and-naming.rst= #functions > > And of course Juris correctly pointed out that 'add' is misleading, > because the behavior is conditional. > > > I would like to know if the internals people think that the addition of > > these functions would be interesting. If there is some interest I will > > prepare a full RFC > > For the reasons mentioned above, I don't see much value in the proposal. > Personally I've rarely needed the functionality in the past and the > cases where I needed it, it was a common enough operation that I could > just place it in a function myself. > > Best regards > Tim D=C3=BCsterhus > --0000000000002a71800648af2c3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't recall ever needing to ensure prefixes or suf= fixes, but I have wanted to prepend or append a string to an array of strin= gs. Maybe there is some demand for "ensuring" when working with p= hone numbers or product SKUs. I don't know.

=
Whatever logic is required for a given scenario, does thi= s need to be built into the core? I once asked about adding array_transpose= () to the core, and the response boiled down to: PHP doesn't need a cor= e function for every possible data manipulation.

Topically, circa 2024-03-24, I proposed to modify substr= _replace() which is a solid go-to for prepending, but not appending. (Subje= ct: "Proposal: Make $offset of substr_replace null by default") T= his is because the offset parameter does not accept null.=C2=A0 Food for th= ought.

=C2=A0substr_repl= ace(
=C2=A0 =C2=A0 =C2=A0array|string $string,
=C2=A0 =C2=A0 =C2=A0ar= ray|string $replace,
=C2=A0 =C2=A0 =C2=A0array|int $offset,
=C2=A0 = =C2=A0 =C2=A0array|int|null $length =3D null
=C2=A0): string|array
=

Contextual usages:
- [Add prefix string to each value of a flat array][https://stackoverflow.com/a/= 78210830/2943403]

-[= Fastest way to add a prefix to all array keys?][https://stackoverflow.com/a/76196482/2943403<= /a>]


Mick

On Sun, 18 Jan 2026, 21:30 Tim D=C3=BCsterhus, <tim@bastelstu.be> wrote:
Hi

On 1/16/26 20:16, Barel wrote:
> Nevertheless, the idea is that in php code many times we have to deal = with
> prefixes or suffixes of strings, this comes up a lot when you are deal= ing
> with file names or urls. Some examples

=C2=A0From the back of my mind I seem to remember that this was previously =
proposed with similar use cases, since I can remember saying the same
I'm saying here before:

Filenames and URLs are probably the worst possible use case for this
feature, since they are =E2=80=9Cstructured=E2=80=9D strings where naively = performing
string operations at best just results in garbage and at worst result in security issues.

> - If the domain includes a initial www part, remove it

This just seems unsafe, since you are likely making assumptions about
URLs you don't own.

> - If the filename includes the .png extension, remove it

basename($filename, ".png");

> - If the URL does not include the http:// schema, add it

Simply adding a prefix will break URLs that already have a scheme. Use
PHP 8.5's URI extension instead.

> - If the URL is missing a trailing slash, add it
> - If the URL starts with http://, change it to https://

URI extension.

> - If the filename ends in .jpeg, change it to .jpg

Here you probably want to have more than one mapping (e.g. .htm to
.html), so you would probably use a combination of `pathinfo()` and a
lookup table.

> function replace_prefix(string $source, string $prefix, string $replac= e):
> string
> function replace_suffix(string $source, string $suffix, string $replac= e):
> string
>
> Replace a prefix or suffix in a string it the string has it

This parameter order is inconsistent with both str_replace and
preg_replace, which are likely the two closest existing functions we have.<= br>
Naming-wise these functions should definitely start with a
`str_(pre|suf)fix_` prefix for proper grouping and autocompletion. Thus:
- str_prefix_add()
- str_prefix_remove()
- str_prefix_replace()
- str_suffix_add()
- str_suffix_remove()
- str_suffix_replace()

See also the corresponding policy:
https:= //github.com/php/policies/blob/main/coding-standards-and-naming.rst#functio= ns

And of course Juris correctly pointed out that 'add' is misleading,=
because the behavior is conditional.

> I would like to know if the internals people think that the addition o= f
> these functions would be interesting. If there is some interest I will=
> prepare a full RFC

For the reasons mentioned above, I don't see much value in the proposal= .
Personally I've rarely needed the functionality in the past and the cases where I needed it, it was a common enough operation that I could
just place it in a function myself.

Best regards
Tim D=C3=BCsterhus
--0000000000002a71800648af2c3e--