Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108565 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3390 invoked from network); 14 Feb 2020 11:59:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Feb 2020 11:59:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3BAFF1804E6 for ; Fri, 14 Feb 2020 02:14:27 -0800 (PST) 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-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (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 ; Fri, 14 Feb 2020 02:14:26 -0800 (PST) Received: by mail-ed1-f54.google.com with SMTP id g19so10538259eds.11 for ; Fri, 14 Feb 2020 02:14:26 -0800 (PST) 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=BzV8Wh3K6kHWfg7EJ2SsTbtd5BKinHOC/P3e26N/wU8=; b=HfK4Yw6x7nEzKNKZYC+y4N5agvsxRVoAh9SqjIJAF6fwL+E855EnhOFcahhnu1PbwO EnSZm12Lx2f1WrT3pahWfBwLNlikup4V8AeIAKnNI33zE0AREQif5q/kvcZvv+eS/WfX Ti5WziKJ0bnaC/u8LVmbx8d25zSOgNwbFamY1XjW8kiop555OcKGG8hH91D2kh3SaCrv SMIuFjqgHXvO+/uM12Dj8MUlWLTohUHfZctE0Hz5qURK00Dx+vnBl3ULfxMlCi2hz2v5 1/WXNWFmD7uU6RlEVTOxDE1VUVvKBUCmlBwRF/QWOP6DjiROpCYXFAEAHRF4+lcKTkUv oCpA== 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=BzV8Wh3K6kHWfg7EJ2SsTbtd5BKinHOC/P3e26N/wU8=; b=V+IpS2jrzJhy1X+sAiYnaM/LWwefzH7vyOGUDtVdlMLvh44R6+0iLL3eO664BFl4St IRjeFjYYvksX8nw13HC4eLpIa2AQ4h61QJAcEvGgJ4D9TopoY48xOOYnbF9aQbqQ9fTj 7wwRBESNy7LEGP1aEjx0wap1h6gXKZa0KpPBjv/8/4Dl4LXTRZO+Qfj1uRJcL0EFz/lE +KTAD+yr6XUFci9I/W4ljGunW5ghCgwSV/XGZlBqs8fTOd/f4C5XVQzF/69K9S+dhluX VIaSGbInOyz0v9oaoc/5rqkIRr4F88nbNtStH2WR3FclaemIS6ct2kskhQ35W0mZuLFF 2hxw== X-Gm-Message-State: APjAAAWg4GjM+0ZGAOqMXlwrzSukk0itIxwToZ3Tqa6NcufZKuadF9WR iCJADyXwoD4IRIiMCOivaEOzMEmWlxBmfDnExjw= X-Google-Smtp-Source: APXvYqzGrZcC1gNonWfrygIhTD6ANCOJ5B4VvmCtnHadORBVrDDDA88WAvZ/lMqx/vRnHKefG+TvSFF3pSadYxNSkOs= X-Received: by 2002:a17:906:2799:: with SMTP id j25mr2326044ejc.216.1581675265634; Fri, 14 Feb 2020 02:14:25 -0800 (PST) MIME-Version: 1.0 References: <4a0f4d30-c8d3-0274-413f-0f4c582418d0@aegir.sexy> In-Reply-To: <4a0f4d30-c8d3-0274-413f-0f4c582418d0@aegir.sexy> Date: Fri, 14 Feb 2020 11:14:13 +0100 Message-ID: To: Aegir Leet Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary="0000000000005bb754059e86784a" Subject: Re: [PHP-DEV] Proposal for a new basic function: str_contains From: george.banyard@gmail.com ("G. P. B.") --0000000000005bb754059e86784a Content-Type: text/plain; charset="UTF-8" On Fri, 14 Feb 2020 at 10:58, Aegir Leet wrote: > I generally like the idea, but it seems many (most?) real-world > implementations actually use mb_strpos() !== false by default. > > > https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215 > > https://github.com/illuminate/support/blob/6eff6cff19f7ad5540b9a61a9fb3612ca8218c19/Str.php#L157-L166 > > So there should definitely be an mb_str_contains in ext/mbstring in > addition to the regular str_contains proposed here. > The biggest reason to have an mb_* variant if for when comparing with case insensitivity. The only other reason is if you need to check a string which is in a different encoding, which is, I'm assuming, is a quasi non-existent problem as everything things is UTF-8 nowadays. The reason why I personally voted no on the previous RFC was that I don't see the value of having functions checking if a string starts/ends with a sequence but not a general one. Moreover, checking for a substring to start/end a string seems to be fitting for the current strpos functions. This function on it's own is way more reasonable and useful to add IMHO Best regards George P. Banyard --0000000000005bb754059e86784a--