Adding new closing tag =?> for keeping trailing newline

  117852
June 5, 2022 08:23 sji@sj-i.dev (shinji igarashi)
Hello everyone,

I'd like to propose adding a new closing tag `=?>` to the language.

PHP currently removes the newline character immediately following
the closing tag `?>`.

With the new closing tag `=?>`,  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
  117853
June 5, 2022 21:31 davidgebler@gmail.com (David Gebler)
On Sun, Jun 5, 2022 at 9:24 AM shinji igarashi <sji@sj-i.dev> wrote:

> Hello everyone, > > I'd like to propose adding a new closing tag `=?>` 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 within the control of the PHP code block. Alternatively it's also enough in the case of plain text or wherever else this matters to you to just add a space after the closing tag before the newline (granted there may be niche situations 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 the 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 `=?>`, 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 > >
  117856
June 5, 2022 22:36 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年6月6日(月) 6:31 David Gebler <davidgebler@gmail.com>:
> > On Sun, Jun 5, 2022 at 9:24 AM shinji igarashi <sji@sj-i.dev> wrote: >> >> Hello everyone, >> >> I'd like to propose adding a new closing tag `=?>` 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 within the control of the PHP code block. Alternatively it's also enough in the case of plain text or wherever else this matters to you to just add a space after the closing tag before the newline (granted there may be niche situations 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 the 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 `=?>`, 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 >>
  117854
June 5, 2022 21:54 mark@demon-angel.eu (Mark Baker)
On 05/06/2022 10:23, shinji igarashi wrote:
> I'd like to propose adding a new closing tag `=?>` to the language. > > PHP currently removes the newline character immediately following > the closing tag `?>`.
So we would have 4 possible combinations that developers could apply in their code, two existing open/close settings and two new combinations, the first you explain but also What should PHP do when it encounters this combination of opening/closing tags? -- Mark Baker _________ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP
  117857
June 5, 2022 22:40 sji@sj-i.dev (shinji igarashi)
Hello!

> It should behave exactly the same as the existing closing tag,
except that it does not erase the trailing newline character. Thanks! -- Shinji Igarashi 2022年6月6日(月) 6:54 Mark Baker <mark@demon-angel.eu>:
> > On 05/06/2022 10:23, shinji igarashi wrote: > > I'd like to propose adding a new closing tag `=?>` to the language. > > > > PHP currently removes the newline character immediately following > > the closing tag `?>`. > > So we would have 4 possible combinations that developers could apply in > their code, two existing open/close settings > > > > > > and two new combinations, the first you explain > > > > but also > > > > What should PHP do when it encounters this combination of > opening/closing tags? > > > -- > Mark Baker > > _________ > |. \ \-3 > |_J_/ PHP | > || | __ | > || |m| |m| > > I LOVE PHP > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
  117861
June 6, 2022 22:47 shinji.igarashi@gmail.com (shinji igarashi)
Hello!

I asked for opinions on reddit also.
https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/

Popularity on reddit and acceptance by people with voting rights on
internals can be different, but it seems that, at least in its current
form, this proposal would have a hard time winning the vote.

Until I can come up with a stronger persuasion or a nicer way of
doing this, I don't feel it has a chance to win, so I'm withdrawing
from this proposal for now and going to work on something else.

Thanks for taking a look!

--
Shinji Igarashi

2022年6月5日(日) 17:23 shinji igarashi <sji@sj-i.dev>:
> > Hello everyone, > > I'd like to propose adding a new closing tag `=?>` to the language. > > PHP currently removes the newline character immediately following > the closing tag `?>`. > > With the new closing tag `=?>`, 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
  117866
June 7, 2022 15:27 landers.robert@gmail.com (Robert Landers)
On Mon, Jun 6, 2022 at 6:47 PM shinji igarashi
igarashi@gmail.com> wrote:
> > Hello! > > I asked for opinions on reddit also. > https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/ > > Popularity on reddit and acceptance by people with voting rights on > internals can be different, but it seems that, at least in its current > form, this proposal would have a hard time winning the vote. > > Until I can come up with a stronger persuasion or a nicer way of > doing this, I don't feel it has a chance to win, so I'm withdrawing > from this proposal for now and going to work on something else. > > Thanks for taking a look! > > -- > Shinji Igarashi > > 2022年6月5日(日) 17:23 shinji igarashi <sji@sj-i.dev>: > > > > Hello everyone, > > > > I'd like to propose adding a new closing tag `=?>` to the language. > > > > PHP currently removes the newline character immediately following > > the closing tag `?>`. > > > > With the new closing tag `=?>`, 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 >
FWIW, I think it makes a lot of sense, having used golang's template language (not everyone is generating HTML with PHP). I think you may just be dealing with a vocal minority and it would be worth putting to an actual vote. Even if it fails, we'll learn something the next time someone wants to change something like this.
  117868
June 7, 2022 17:27 craig@craigfrancis.co.uk (Craig Francis)
On 7 Jun 2022, at 16:27, Robert Landers robert@gmail.com> wrote:
> > On Mon, Jun 6, 2022 at 6:47 PM shinji igarashi igarashi@gmail.com> wrote: >> >> Hello! >> >> I asked for opinions on reddit also. >> https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/ >> >> Popularity on reddit and acceptance by people with voting rights on internals can be different, but it seems that, at least in its current form, this proposal would have a hard time winning the vote. >> > > FWIW, I think it makes a lot of sense, having used golang's template language (not everyone is generating HTML with PHP). I think you may just be dealing with a vocal minority and it would be worth putting to an actual vote. Even if it fails, we'll learn something the next time someone wants to change something like this.
So long as it's not likely to cause problems, I think `` is a bit easier to read than - `` - `` - `` It's of things that probably won't have strong supporters, but might be nice to have (I find some junior developers question why their HTML output can be a bit messy, not that it's really a problem, but it's there). Craig
  117870
June 8, 2022 03:34 pollita@php.net (Sara Golemon)
On Tue, Jun 7, 2022 at 10:27 AM Robert Landers robert@gmail.com>
wrote:
> FWIW, I think it makes a lot of sense, having used golang's template > language (not everyone is generating HTML with PHP). I think you may > just be dealing with a vocal minority and it would be worth putting to > an actual vote. Even if it fails, we'll learn something the next time > someone wants to change something like this. >
While my gut response for the new end tag is in the "no" column, I do wonder if we can accommodate "non-html" scenarios in a broader (maybe more palatable?) way by assuming that if you want the newline to be respected on one line, you probably want it that way for the whole file.
  117871
June 8, 2022 06:15 me@jhdxr.com ("=?ISO-8859-1?B?Q0hVIFpoYW93ZWk=?=")
> declare(ignore_newline_after_close_tag=false); // defaults to true, i.e > existing behavior
> This would avoid any new syntax rules, but still provide the ability for > php-as-template-engine to behave in the user's preferred mode.
I thought it's a consensus on internal that we should avoid such runtime configuration that can affect code behaviour, otherwise we have a long list to check when we debug or ask for help. Yeah I know we already have a lot, and it's a easy and straightforward solution to add a switch for this kind of issues, but we should be careful to introduce a new one. (Personlly I was a supporter for runtime configuration as well, but I'm not able to convince myself to ignore or defeat that argument.) Regards, CHU Zhaowei
  117872
June 8, 2022 07:07 ocramius@gmail.com (Marco Pivetta)
On Wed, 8 Jun 2022, 08:15 CHU Zhaowei, <me@jhdxr.com> wrote:

> > > declare(ignore_newline_after_close_tag=false); // defaults to true, i.e > > existing behavior > > > This would avoid any new syntax rules, but still provide the ability for > > php-as-template-engine to behave in the user's preferred mode. > > I thought it's a consensus on internal that we should avoid such runtime > configuration that can affect code behaviour, otherwise we have a long list > to check when we debug or ask for help. Yeah I know we already have a lot, > and it's a easy and straightforward solution to add a switch for this kind > of issues, but we should be careful to introduce a new one. (Personlly I > was a supporter for runtime configuration as well, but I'm not able to > convince myself to ignore or defeat that argument.) >
That would be a top-of-file `declare`, not a runtime configuration.
>
  117873
June 8, 2022 09:37 claude.pache@gmail.com (Claude Pache)
> Le 8 juin 2022 à 05:34, Sara Golemon <pollita@php.net> a écrit : > > > declare(ignore_newline_after_close_tag=false); // defaults to true, i.e > existing behavior > > This would avoid any new syntax rules, but still provide the ability for > php-as-template-engine to behave in the user's preferred mode. >
No, because the user’s preferred mode is not a global one, it is a local one. You do not want to keep newlines in the following situation: ``` * line 1 * line 2 * line 3 * line 4 ``` With a global switch, not only you have failed to solve the real problem (doing the Right Thing with newlines), but also you have created another one (looking at the top of the file in order to understand the code). You have the worst of both world. —Claude
  117875
June 8, 2022 14:14 chasepeeler@gmail.com (Chase Peeler)
On Wed, Jun 8, 2022 at 5:37 AM Claude Pache pache@gmail.com> wrote:

> > > > Le 8 juin 2022 à 05:34, Sara Golemon <pollita@php.net> a écrit : > > > > > > > declare(ignore_newline_after_close_tag=false); // defaults to true, i..e > > existing behavior > > > > This would avoid any new syntax rules, but still provide the ability for > > php-as-template-engine to behave in the user's preferred mode. > > > > No, because the user’s preferred mode is not a global one, it is a local > one. You do not want to keep newlines in the following situation: > > ``` > * line 1 > > * line 2 > * line 3 > > * line 4 > ``` > > With a global switch, not only you have failed to solve the real problem > (doing the Right Thing with newlines), but also you have created another > one (looking at the top of the file in order to understand the code). You > have the worst of both world. > > Declare statements shouldn't have any impact outside of the file in which
they appear. Declaring strict types doesn't force other classes that interact with the defined class to also use strict types. A declare to change how newlines after closing tags are handled within a single file forces anything that uses the classes/functions defined in that file to know that it handles them in a possibly different ways. I personally don't see a need for a new closing tag. I'm not usually swayed by the "it adds confusion to the language" and would be against removing such a tag if it existed and that was the reason for removing it. However, I do think it's something to consider when adding something new to the language. In this case, I don't think the positives outweigh the negatives, especially in light of the fact it's really easy to accomplish this without changes.
> —Claude > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  117876
June 8, 2022 15:28 guilliam.xavier@gmail.com (Guilliam Xavier)
> Declare statements shouldn't have any impact outside of the file in which > they appear. Declaring strict types doesn't force other classes that > interact with the defined class to also use strict types. A declare to > change how newlines after closing tags are handled within a single file > forces anything that uses the classes/functions defined in that file to > know that it handles them in a possibly different ways.
Indeed (via includes)... Also consider this hypothetical example: ``` - 0 - - 4 ``` Note the use of both ?> and =?> *within the same file*; a declare would not allow that.
> I personally don't see a need for a new closing tag. I'm not usually swayed > by the "it adds confusion to the language" and would be against removing > such a tag if it existed and that was the reason for removing it. However, > I do think it's something to consider when adding something new to the > language. In this case, I don't think the positives outweigh the negatives, > especially in light of the fact it's really easy to accomplish this without > changes.
I personally am generally in favor of removing "magic" stuff (even if this isn't exactly proposing that but to add a "straightforward" alternative). Other example, consider starting from this: ``` - first - foo bar - last ``` Now if you want to "variablize" the `foo` part, just change it to e.g. ``; but for `bar` you have to remember and write e.g. `` (or add a blank line after it [or a trailing space... no, please don't]), only because it happens to be at the end of a line (and don't forget to re-change it if you later append a `qux`)... PS: An[other] argument against could be something like "please don't add more things encouraging the use of PHP as a templating engine (unsafe etc.)", but the main target is *non*-HTML (e.g. Markdown or raw text) templates. -- Guilliam Xavier
  117878
June 8, 2022 18:15 sji@sj-i.dev (shinji igarashi)
> declare(ignore_newline_after_close_tag=false);
Thanks for coming up with another idea! As others have already pointed out, disabling the closing tag from eating trailing newline throughout the file would be inconvenient if we want to use control statements in the template. However, we currently only have one closing tag, but we already have two opening tags. So, for example, if we use declare to disable the newline eating only when closing a PHP block started with ` - I'm honestly not sure if adding a declare switch is better received than a new closing tag, though. Thanks! -- Shinji Igarashi 2022年6月8日(水) 12:34 Sara Golemon <pollita@php.net>:
> > On Tue, Jun 7, 2022 at 10:27 AM Robert Landers robert@gmail.com> wrote: > > FWIW, I think it makes a lot of sense, having used golang's template > > language (not everyone is generating HTML with PHP). I think you may > > just be dealing with a vocal minority and it would be worth putting to > > an actual vote. Even if it fails, we'll learn something the next time > > someone wants to change something like this. > > > > While my gut response for the new end tag is in the "no" column, I do wonder if we can accommodate "non-html" scenarios in a broader (maybe more palatable?) way by assuming that if you want the newline to be respected on one line, you probably want it that way for the whole file. > > declare(ignore_newline_after_close_tag=false); // defaults to true, i.e existing behavior > > This would avoid any new syntax rules, but still provide the ability for php-as-template-engine to behave in the user's preferred mode. > > -Sara
  117879
June 8, 2022 18:44 petk@php.net (Peter Kokot)
On Wed, 8 Jun 2022 at 20:16, shinji igarashi <sji@sj-i.dev> wrote:

> > declare(ignore_newline_after_close_tag=false); > > Thanks for coming up with another idea! > > As others have already pointed out, disabling the closing tag from > eating trailing newline throughout the file would be inconvenient if > we want to use control statements in the template. > > However, we currently only have one closing tag, but we already > have two opening tags. So, for example, if we use declare to disable > the newline eating only when closing a PHP block started with ` it can produce the desired output. > > > > - > > > I'm honestly not sure if adding a declare switch is better received > than a new closing tag, though. > > Thanks! > > -- > Shinji Igarashi > > 2022年6月8日(水) 12:34 Sara Golemon <pollita@php.net>: > > > > On Tue, Jun 7, 2022 at 10:27 AM Robert Landers robert@gmail.com> > wrote: > > > FWIW, I think it makes a lot of sense, having used golang's template > > > language (not everyone is generating HTML with PHP). I think you may > > > just be dealing with a vocal minority and it would be worth putting to > > > an actual vote. Even if it fails, we'll learn something the next time > > > someone wants to change something like this. > > > > > > > While my gut response for the new end tag is in the "no" column, I do > wonder if we can accommodate "non-html" scenarios in a broader (maybe more > palatable?) way by assuming that if you want the newline to be respected on > one line, you probably want it that way for the whole file. > > > > > declare(ignore_newline_after_close_tag=false); // defaults to true, i..e > existing behavior > > > > This would avoid any new syntax rules, but still provide the ability for > php-as-template-engine to behave in the user's preferred mode. > > > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php
I'm just adding a few cents into this discussion for some inspiration. If I'm not mistaken, the Twig template engine, for example, has such a difference integrated in the output tag and the statement tag. The statement tag ({% %}) behaves as PHP tag, it removes the newline character. The outputting tag ({{ }}) adds a newline at the end. See this: https://twigfiddle.com/pto9qx More info about this here: https://twig.symfony.com/doc/3.x/templates.html#whitespace-control So, it is actually important to have such functionality in templates.
  117877
June 8, 2022 17:50 sji@sj-i.dev (shinji igarashi)
Hello!

> I think you may just be dealing with a vocal minority and it would be worth putting to > an actual vote. Even if it fails, we'll learn something the next time > someone wants to change something like this.
Thanks for the feedback! In my experience over the years of watching internals, many controversial language changes do not survive the voting. Two Yeses are balanced against one No, so there needs to be overwhelming agreement. Surely it could at least be said that even if it fails, it is easier for someone who later comes up with a similar idea to find past efforts if the RFC is drafted and the results of the voting are there. However, the July 19 Feature Freeze for 8.2 is approaching! So I'll try to write an RFC on this proposal later for 8.3. For now, I will look at the interpreter code and see if I can come up with another proposal and its implementation that is a little less controversial (like constants on traits) until the 8.2 effective deadlines. My ability to write English is very limited, so probably I cannot proceed with multiple proposals in parallel. Thanks! -- Shinji Igarashi 2022年6月8日(水) 0:27 Robert Landers robert@gmail.com>:
> > On Mon, Jun 6, 2022 at 6:47 PM shinji igarashi > igarashi@gmail.com> wrote: > > > > Hello! > > > > I asked for opinions on reddit also. > > https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/ > > > > Popularity on reddit and acceptance by people with voting rights on > > internals can be different, but it seems that, at least in its current > > form, this proposal would have a hard time winning the vote. > > > > Until I can come up with a stronger persuasion or a nicer way of > > doing this, I don't feel it has a chance to win, so I'm withdrawing > > from this proposal for now and going to work on something else. > > > > Thanks for taking a look! > > > > -- > > Shinji Igarashi > > > > 2022年6月5日(日) 17:23 shinji igarashi <sji@sj-i.dev>: > > > > > > Hello everyone, > > > > > > I'd like to propose adding a new closing tag `=?>` to the language. > > > > > > PHP currently removes the newline character immediately following > > > the closing tag `?>`. > > > > > > With the new closing tag `=?>`, 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 > > > > FWIW, I think it makes a lot of sense, having used golang's template > language (not everyone is generating HTML with PHP). I think you may > just be dealing with a vocal minority and it would be worth putting to > an actual vote. Even if it fails, we'll learn something the next time > someone wants to change something like this.
  117874
June 8, 2022 12:47 guilliam.xavier@gmail.com (Guilliam Xavier)
Hi,



Thanks for proposing! this "feature" bothered me more than once...
Maybe just 2 days (of internals and Reddit feedback) is a bit early to
"give up" (but I won't blame you either).

FWIW, the Twig templating engine has distinct delimiters for output
({{ ... }}) and control ({% ... %}), and the former does *not* eat
newline; for the latter you can use ~%}
(https://twigfiddle.com/54daye), and there are other "whitespace
control" options
(https://twig.symfony.com/doc/3.x/templates.html#whitespace-control).

For PHP, if we could ignore BC, I would rather have ?> not eat
newline, and add an optional way to do it; but we can't, so I guess
the opposite (e.g. your =?>) is the best we could hope for.

Regards,

-- 
Guilliam Xavier
  117883
June 8, 2022 23:09 sji@sj-i.dev (shinji igarashi)
Hi, thanks for supporting this!

> Maybe just 2 days (of internals and Reddit feedback) is a bit early to > "give up"
I kinda thought so too after I declared defeat, but... The Feature Freeze for 8.2 is July 19! The RFC process requires two weeks each for discussion and voting. If we want to add something good to 8.2, we have to draft the RFC and start discussing it on internals by June 21 at the latest. So I may be a bit impatient, yeah. Other template engines, such as twig or ERB, often have flexible ways of handling whitespace and newline characters around tags. I'm not trying to make PHP more sophisticated to compete with them, but it seemed that just handling trailing newlines would be easy to implement, doesn't complicate the engine, so I proposed this. I am encouraged by the supportive people and will try to work on it again when I have more time to use. Thanks! -- Shinji Igarashi 2022年6月8日(水) 21:48 Guilliam Xavier xavier@gmail.com>:
> > Hi, > > > https://github.com/php/php-src/pull/8708 > > > https://www.reddit.com/r/PHP/comments/v5le6h/adding_new_closing_tag_for_keeping_trailing/ > > Thanks for proposing! this "feature" bothered me more than once... > Maybe just 2 days (of internals and Reddit feedback) is a bit early to > "give up" (but I won't blame you either). > > FWIW, the Twig templating engine has distinct delimiters for output > ({{ ... }}) and control ({% ... %}), and the former does *not* eat > newline; for the latter you can use ~%} > (https://twigfiddle.com/54daye), and there are other "whitespace > control" options > (https://twig.symfony.com/doc/3.x/templates.html#whitespace-control). > > For PHP, if we could ignore BC, I would rather have ?> not eat > newline, and add an optional way to do it; but we can't, so I guess > the opposite (e.g. your =?>) is the best we could hope for. > > Regards, > > -- > Guilliam Xavier