Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115111 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 70759 invoked from network); 24 Jun 2021 11:20:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Jun 2021 11:20:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 127871804DB for ; Thu, 24 Jun 2021 04:39:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 24 Jun 2021 04:39:03 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id x24so9669274lfr.10 for ; Thu, 24 Jun 2021 04:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mnSftPHRiBBNxjV6107qcFsD/4kk7MnxS7mEt1lvBIo=; b=a2YmEYNe4yWlzxMqLI5nx/e12eF4hr65GaltEqPLBHGFMPDreBRf+UiDmlOfBZRrFb /3kiL+/hxJwTViKAmdwT1aYmo6Z/0/XIcqV1lw4KqGaITETTDpbd+VqLy5eVjRZIx6Bd 8j8QwehrMXaubK25+8H0e9B+xTFygIq+xp5w4dJj8tSMQaufv7eAkx60OfecOAXaVqJz 8YXeWPDucp/THdyvoZmoxfkmijF4HSkfP4Y57vqk8NWs9DXRSFDih+gMpYfNjWKkZvQ3 Jwi7waUSZ2eoeMhJTxKnquIb6u1fmyAQZKvPxxU2GXVZOIKQ4cdVWivwtwrrCRvdzUX3 3wLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mnSftPHRiBBNxjV6107qcFsD/4kk7MnxS7mEt1lvBIo=; b=W5zmgXRv5DYmPOZWOgziNA92PgR5k/MPDwMDzdNezZfQt2cb4Nt1VnhDNHFAuwJfgW 7Qg8ygkd5qt5vvGyJqhz8N2fwshAJ/0Mpbm4w5FE6eUsjSxOT5OVVFXI+seuz/rz6wBz Mkn1nn8q5/cdjDWvjJBfYlEzLOS+0zfgR/9KsE8bJXTZBdya+eTHjAxIvts+yZd8ljWr aEwFTt/HYSQa2GhxbtRWoY43gr2wXqFUONpPOw15c73I4mjk4u7UicNSHGJbQI9kPX+O yom00iQFNx1iiOTC6hv533qRsMjIIP9mLg2MRsdtm832fPOi1fVuZbNUbOy/OpV1m71E hOSw== X-Gm-Message-State: AOAM532fZi4S5xtROvYkifoAmjpfjYgRhfnlmVaSmAQ2qSDH3V4dwI06 71yrj4do4KMvrJtaOw2NITjerNaxAQXlEmpftg== X-Google-Smtp-Source: ABdhPJyIkFsaV9CJ2YsXWrbfSzENbmi4qorjaseVLZGYZlvpR4OXNMcR9KJ4ws7u+gIX5kyFNkgfS4nYTARh1ejApqQ= X-Received: by 2002:ac2:4198:: with SMTP id z24mr3602878lfh.335.1624534739922; Thu, 24 Jun 2021 04:38:59 -0700 (PDT) MIME-Version: 1.0 References: <012901d7683a$446a7ba0$cd3f72e0$@gmail.com> In-Reply-To: Date: Thu, 24 Jun 2021 13:38:49 +0200 Message-ID: To: Kamil Tekiela Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000019310d05c5817878" Subject: Re: [PHP-DEV] Introduce str_left/right In 8.1 From: guilliam.xavier@gmail.com (Guilliam Xavier) --00000000000019310d05c5817878 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 24, 2021 at 1:17 PM Kamil Tekiela wrote: > I am against adding these functions, but for different reasons than Sara > and George. > If we add str_left and str_right then there should be a corresponding > variant in mbstring. The byte-string functions are rarely useful. Adding > these functions to mbstring unnecessarily complicates the extension for > little to no gain. > So you seem to relate to Christoph's (and Rowan's) point. > Another point is that if we decide to add them, then we will bikeshed > forever in an unresolvable manner about the name. Should it be called > str_left or strleft? Current functions don't have a naming convention, so > using either variant will be wrong. > To be fair, most "strxxx" functions were historically more-or-less copied from C; most recent additions have been "str_xxx". > Personally, I find substr to be more clear about the intent. I know that I > am asking for a part of the string. Whereas str_left doesn't convey an > action immediately. Without knowing its purpose I wouldn't know if it will > pad the string from the left, strip characters from left, or take the > leftmost part of the string. > True, I can also imagine bikeshed like "str_leftmost", "str_start", "str_first[_n]" (and same for rightmost/end/last)... > Don't take it the wrong way, but I think it's a waste of time to implement > a function that doesn't even need a polyfill in the userland. > > Regards, > Kamil > -- Guilliam Xavier --00000000000019310d05c5817878--