Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100437
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6dd0d2d1-3a4b-5b42-8396-0a6456a97f11@tekwire.net>
References: <8C.6B.10715.4A4A0B95@pb1.pair.com> <6dd0d2d1-3a4b-5b42-8396-0a6456a97f11@tekwire.net>
Date: Thu, 7 Sep 2017 12:29:37 +0200
Message-ID: <CAF+90c98HRJjSW2tuueUNM-0bVXNK9vhtcxGWY6-La38pC2okg@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113f9d06f9268d055896ef47"
Subject: Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113f9d06f9268d055896ef47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 7, 2017 at 12:11 PM, Fran=C3=A7ois Laupretre <francois@tekwire.=
net>
wrote:

> Hi Andrea,
>
>
> Le 07/09/2017 =C3=A0 03:45, Andrea Faulds a =C3=A9crit :
>
>> Hi everyone,
>>
>> This is the tiniest of issues, but it's bugged me for a long time and
>> makes the HTML produced by PHP code less readable than it out to be.
>> Specifically, PHP ignores a newline immediately following a ?> tag. The
>> reason for this is, from what I recall, to prevent issues where whitespa=
ce
>> at the end of a PHP file is echoed before headers can be sent. On UNIX i=
n
>> particular, all text files (should) end in a newline, so this is a
>> reasonable and necessary feature.
>>
>> However, for ?> tags anywhere that aren't right at the end of the file,
>> this is just a nuisance that makes for messy output. For example, HTML
>> output that should look like:
>>
>> <table>
>>     <tr>
>>        <td>foo</td>
>>        <td>bar</td>
>>     </tr>
>> </table>
>>
>> May instead end up looking something like:
>>
>> <table>    <tr>
>>        <td>foo</td>       <td>bar</td>
>>     </tr></table>
>>
>> Of course, HTML doesn't matter so much, it'll render the same to the
>> end-user. However, for outputting e.g. plain text, newlines can be
>> significant, and so you have to insert an ugly and surprising extra newl=
ine
>> following a tag.
>>
>> Would anyone object to me changing how PHP handles this so that only the
>> final ?> tag consumes its following newline, and only at the end of the
>> file?
>>
>> Thanks!
>>
>
> +1 to create a PHP8 branch and change the behavior there. not in PHP7.
>
> Once again, some may think it's too early but, IMO, we should create such
> a branch and encourage RFCs and changes targeting next major version to b=
e
> announced, discussed, implemented, and tested as soon as possible. This i=
s
> the only way to introduce BC breaks while minimizing their impact. We saw
> this when talking about PHP7 features : when proposed too late, changes
> introducing BC breaks generally must be rejected, whatever their value.
>
> Regards
>
> Fran=C3=A7ois
>

New branches cause a lot of additional overhead for core developers.
Changes have to merged across all actively supported branches, commonly
with NEWS file adjustments. Depending on where we are in the release cycle
right now, we already have 3-4 active branches -- we don't need to add to
that.

I think it's fine to start targeting PHP 8 now with RFCs, but
implementation work should be done outside of php-src. It is more cost
effective for one person to rebase their code two years down the line than
it is for everybody to do extra work every time they commit something.
(Alternatively we would have to change our development model so that
branches are not synchronized at all times.)

Nikita

--001a113f9d06f9268d055896ef47--