Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117856 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36674 invoked from network); 5 Jun 2022 20:50:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Jun 2022 20:50:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 018CD1801FD for ; Sun, 5 Jun 2022 15:36:16 -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=0.5 required=5.0 tests=BAYES_20, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 5 Jun 2022 15:36:16 -0700 (PDT) Received: by mail-ej1-f41.google.com with SMTP id gl15so11860621ejb.4 for ; Sun, 05 Jun 2022 15:36:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wA3OXiXX86LpRvNtFNcg5Kgq+/gdpYf+dbvD2+Qwp+c=; b=YfrBIuVhn2Fs1W6ZtWRjYj3Q3ccorJfXNxQLGNHDM9nYXp/THHxYPTNA+wQtdioAf2 2XPGcWwmuKx5+pTBLji1/jQ1Tc+3ybLP6Fp5RcoO0dphTZgfHFBiIbTMts/xDP8WIS5g XL5MaM8tuUVk7tGFRsy8e3ZXG2JkmL89NXnosZJgFbZj3gg/kvdQGClqOhM0dTOpouO8 IroFQ8NU5Xwpj252/9zmUg9sb3VgwMLkwX1EAB0eNXH9KuQrkGf+cs30GkSangtLkg5C /aXJ8WEnRyVSAcHdHITExHE5F0w/9Oe87iPMgB3b0riegya8NnGVt02y49/GemQP1vbG oRpw== X-Gm-Message-State: AOAM530XxWIc/itZ5uKpkM0zAKWb9sQugmF5Y7aOODKmJGu+XqjWRRFc rJbaEGn2aAoDsellfWPlN4PpUNh1bPgy8g== X-Google-Smtp-Source: ABdhPJzcaCaOR6md9ReS/vCz2xSK+tJUzzxHa+urMDwK6va65S5zbqfVlXy/hMt39j1HXq3gLbq9PQ== X-Received: by 2002:a17:906:5393:b0:711:ca9c:5589 with SMTP id g19-20020a170906539300b00711ca9c5589mr3220122ejo.350.1654468575009; Sun, 05 Jun 2022 15:36:15 -0700 (PDT) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com. [209.85.221.45]) by smtp.gmail.com with ESMTPSA id n24-20020a1709062bd800b006fee28d459csm5672518ejg.224.2022.06.05.15.36.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Jun 2022 15:36:14 -0700 (PDT) Received: by mail-wr1-f45.google.com with SMTP id t13so17583707wrg.9 for ; Sun, 05 Jun 2022 15:36:14 -0700 (PDT) X-Received: by 2002:a5d:6d4b:0:b0:210:d2f:655d with SMTP id k11-20020a5d6d4b000000b002100d2f655dmr18443278wri.647.1654468574325; Sun, 05 Jun 2022 15:36:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 6 Jun 2022 07:36:03 +0900 X-Gmail-Original-Message-ID: Message-ID: To: David Gebler Cc: internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Adding new closing tag =?> for keeping trailing newline From: sji@sj-i.dev (shinji igarashi) > or ."\n" Yeah, adding an explicit newline character is a workaround for this. However, what if that output content were moved to a location other than the end of a line when editing the template? It would be necessary to remove the extra newline character each time they move from the end of a line. With this new closing tag, the behavior of the output block can be position-independent. Your concerns are valid and I agree that this is a small difference. What I am not sure about is how many people want this small difference, so I'm asking around in some parts of the community. Thanks for your feedback! -- Shinji Igarashi 2022=E5=B9=B46=E6=9C=886=E6=97=A5(=E6=9C=88) 6:31 David Gebler : > > On Sun, Jun 5, 2022 at 9:24 AM shinji igarashi wrote: >> >> Hello everyone, >> >> I'd like to propose adding a new closing tag `=3D?>` to the language. >> >> PHP currently removes the newline character immediately following >> the closing tag `?>`. > > > Personal opinion, seems like a classic sledgehammer on a nut proposal. I = actually prefer the or ."\n" notation since it= makes it explicitly clear what you're intending to output and keeps it wit= hin the control of the PHP code block. Alternatively it's also enough in th= e case of plain text or wherever else this matters to you to just add a spa= ce after the closing tag before the newline (granted there may be niche sit= uations where this is undesirable). > > It's not a breaking change for any existing code, at least, but for me I = still don't see enough of a benefit that I'd think it was worth adding to t= he language, as any new syntax creates the potential for confusion and user= error. Is this a big enough problem to be worth any change at all? In over= 15 years of writing PHP, I've never once had a situation where closing tag= newline elision has been an issue. > > -Dave > >> >> >> With the new closing tag `=3D?>`, the code should look like this: >> >> ``` >> - >> - >> - >> ``` >> >> and the results it produces would be: >> >> ``` >> - 1 >> - 2 >> - 3 >> ``` >> >> instead of the following: >> >> ``` >> - 1- 2- 3 >> ``` >> >> This addition requires only a one-line modification to the lexer and >> doesn't break BC. The proposed patch is here. >> https://github.com/php/php-src/pull/8708 >> >> Before writing an RFC, I would like to hear your input on whether >> it's worth tackling. >> >> Thanks! >> >> -- >> Shinji Igarashi >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >>