Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102151 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50875 invoked from network); 28 May 2018 19:56:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 May 2018 19:56:16 -0000 Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.15.18 mout.gmx.net Received: from [212.227.15.18] ([212.227.15.18:45765] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/58-01681-EDE5C0B5 for ; Mon, 28 May 2018 15:56:15 -0400 Received: from [192.168.2.114] ([79.222.47.197]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MTSKd-1fnTQK0HCx-00SRp1; Mon, 28 May 2018 21:56:11 +0200 To: Rasmus Schultz , PHP internals References: <29dffbd0-b356-08eb-2232-cd02821a0056@php.net> <4e605b02-fe9e-1128-4c98-e274b2ab375d@php.net> Message-ID: <10f05e5b-e462-360a-c4d2-ad9baffe6981@gmx.de> Date: Mon, 28 May 2018 21:56:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:cKXWuj18hrkAAt1m5LKjI7n4oRGZgTn0S/1xQw2mvDSRYgncXBm ogvdbEzc8Vri64+lQW2zdg/z8nZyozadjpcfKNzN9YhdtzXfzgdnSDWgz013D46tSG3jw/h OSCRqsQ0SLdCEuX5IfIoVxe9cSfV8gfYVntdWR2CNZJWVOwTND+WnGZB5IkKSoiSW6jBAuu +PZeiiwMKKCB4/vkJvt3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:AiulZAr+GSo=:7/UAweevWJ+YOg0VRTFDxv AmgtA9i6NospZLWRgEiFrNEVDhVkiqa5L4hS0oXs/jCV71ghX4GfCiLffsnt4F5+rdyP8Dvpm BnbSdOOQR6XirTrIcW3pQK9h5pEVGxQcwODlSoMyHw7EPjsIMfd+Daym1wZuAy/oIHOjEdsLp EowfuZcglRmgek4b9RJHyaSbgbfaYj5AO6PWxtV3iJAjdvQDILMdQJvOtpXgHvp+g291t3LMX npX9OEoGj4oSgQnOtlsFYoomYfSvp2wI/TeBnzquEJMcrgoqo0XVUgcniHfphYqpOXSBa8WaE Woc1y0N4Wi+sK13dXgu1WB0uPglo48GgNvsm+5nkj+pvS1pNmzdoxtIuL9J2GKisnYZY5pZCe 4yA5fpWZlm/7UgMrI4AaTxVTQ8flMhVkP48vLtre7qzgIvuOYyjUy4vJCYqiNCaAArxLuXnyB ZZ5jC7sQv4wZW6B7GelZT8Cz2GdlN8r3YJQH924FNS2prpNO31d0Z6I5fQxGY5PV+RASpIXn9 fT4OC+6xlludF/Utc8Df4YCrkDfqFdvyyHK4oOsEppFckRar4zZQA+c2/Dq3vNWVLzI0SEsk/ vmGygMDzcJxnckGXHh1GyNApcBjwEBP65PZftJtNcc0hHy8opl0GObPHPA0EJwFBe2picI6JL TX5Yo0UsowIABZ5mF6C/GCNfIhMwZM7UGgJmar50qJPPvmdxjDivcuzMIuPSjEK3xy8kJNE8F hAEVZigGgXYHxw19ynHeBV+16e8SbLBK6ge4bqfW6KHhc2Zrmh+L2k3GYSd/BN1+J09PtQzQZ 8zNDJFU Subject: Re: [PHP-DEV] Parse error: Invalid body indentation level From: cmbecker69@gmx.de ("Christoph M. Becker") On 28.05.2018 at 18:56, Rasmus Schultz wrote: >>> Yes, this is an expected result under the flexible heredoc RFC. To avoid >>> issues, please use a heredoc label that does not occur within the string. >> >> Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP >> 7.3. This breaking change should at least be prominently documented. As of >> right now, I do not see such documentation in UPGRADING. > > Wow, I can't believe I didn't think of this when I reviewed that RFC. > > This is potentially a pretty serious BC break, really - at least in two cases: > > 1. Markdown, where indentation can be irregular as well as meaningful. > > 2. Failing tests! > > The latter could prove rather difficult - getting your tests to pass > under 7.2 and 7.3+ might be far from simple, and at the very least > would require test-helpers that conditionally treat whitespace > differently for 7.3+ and earlier versions. > > Even inline HTML could potentially suffer, if you have
 blocks.
> 
> And on top of these unexpected results and test-failures, of course
> there may be parse errors for inline content with meaningful
> whitespace that was (or wasn't) indented correctly.
> 
> Honestly, are there any cases where existing code *benefits* from
> changing the existing syntax/feature?

No.

> Some people indent inline blocks so that the output ends up with the
> desired indentation, rather than the source-code looking pretty - in
> those cases, whitespace will now be silently removed and the output no
> longer as desired?

No.

> Are we positive it wouldn't be safer to just introduce a slight syntax
> variation for blocks that treat indentation differently?
> 
> (am I blowing this out of proportion?)
It seems that you have not understood the change.  While formerly the
actual string had exactly the noted whitespace at the beginning of the
lines, now the leading whitespace of the line with the closing marker is
also removed for all other lines (but not additional leading
whitespace).  See the first two examples in the “Closing Marker
Indentation” section[1].

The BC break affects only code which has the heredoc/nowdoc identifier
in the body of the string, namely at the beginning of a line (with
optional leading whitespace).

[1]


-- 
Christoph M. Becker