Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114857 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26175 invoked from network); 14 Jun 2021 10:37:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Jun 2021 10:37:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BD7FD1804F4 for ; Mon, 14 Jun 2021 03:53:27 -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,NICE_REPLY_A, 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-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 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 ; Mon, 14 Jun 2021 03:53:27 -0700 (PDT) Received: by mail-ed1-f51.google.com with SMTP id ba2so44117414edb.2 for ; Mon, 14 Jun 2021 03:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MCAfYXXfWsTw60chWTZ3wy5QCX06gEL1YGWsv49akHI=; b=mAK2Nrb7M0tGVMfjvnOL//Rylgy0TngOHg2UaI6B1X1ev2eyzoPoyeeza8N8kvDn3T OaYBlwU0RwpR5s28nIb59Fzh9f6JrbbedL4CzQGG4wmhVervfk4AlqOJ3N1MIH7uSiQx JkqEASByP9gmmiTknQ46cEIhNnnn+4IGvI9ulQ/njpKmFxYmtYhWgzvIS6l8xHHXV2Q8 s4d7Boah5lR85GRheyCIMp3Re/mg9pwv6COjv9TxbyCij8oUvstaDgoTL8dvErRd+6ND NcNghFV5PA5rn/bhBrHYkQG7lQJ6NfKPw0DCRGCTr3Gm/xFqCQwYEd1Gp1wCiC8z2EtE Q58Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MCAfYXXfWsTw60chWTZ3wy5QCX06gEL1YGWsv49akHI=; b=rJAxzeRq4KpVYjtLufpQYyH+c5AWJ20AgxVlJQmVyuVTQnBFjoHWfnid23h09+dFR4 d79ZsKgsC3mc6cp7IB+oN4bJN91jQK3A7pubd/yrv/t6fAz124PsPaqaWbbIWwxvRSMs 3h0z2uM2sDpHC56IEVc0EuIWTmLRu8DJ8ffUU+jZsmk1v/j0or8HdwqJ428NZKat14Zq 2xNkQYcorfHkql24+It2n19wsR78nJ3cJLOlXMFD8DdjzCq6LsvgNu7B2uw08FU/CYYd hq72QNqW7hpoSOaPEoQBbPSDEbKp33URCHDPjRZDUjIGWW1nAkuZDiIxBS+PYWw0/JJM bN+Q== X-Gm-Message-State: AOAM5326RFdIHQhx1AjIoImT/AAzSJ/4JbsUsiZ8ZTzet2HO0aAXmnfn 9Ym/Y5KsBuMni4xkrTxhhgC24PGjYq8= X-Google-Smtp-Source: ABdhPJwEz3IfJLvZ2HiAG7TPYqWnWOnmC40c48i79SVXWPjuprAxTx4VRR5Zhyr6UQL2Laxp2lf07g== X-Received: by 2002:a50:9b42:: with SMTP id a2mr16123823edj.215.1623668006046; Mon, 14 Jun 2021 03:53:26 -0700 (PDT) Received: from ?IPv6:2001:983:6fc5:1:d185:8224:6850:fc93? ([2001:983:6fc5:1:d185:8224:6850:fc93]) by smtp.gmail.com with ESMTPSA id b10sm8792744edf.77.2021.06.14.03.53.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jun 2021 03:53:25 -0700 (PDT) To: internals@lists.php.net References: Message-ID: Date: Mon, 14 Jun 2021 12:53:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] is_literal From: dik.takken@gmail.com (Dik Takken) On 13-06-2021 21:46, someniatko wrote: > Hi! > > From what I understood reading the RFC, this looks like a new type, > "literal string", specifically a subtype of "string". Have you > considered instead of forcing library authors to use `is_literal()` > check everywhere on their input boundary and making sure no place > where input is passed, is forgotten, to let them type their whole > codebase, including internal, against the new `literal-string` type, > which would be enforced by PHP all the time? From my perspective as a > PHP developer, it would serve clearer intent than only checking in a > few places which presumably may take user input, i.e. you could > explicitly state "this function does only work with literal strings". That sounds like a great future extension. Then it would be nice to have the name of the new type match the name of the function that checks for it. In case the existing 'string' type would be paired with a new 'lstring' type the existing is_string() would pair nicely with a new is_lstring() function. Regards, Dik Takken