Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100979 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29589 invoked from network); 28 Oct 2017 12:16:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Oct 2017 12:16:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender) X-PHP-List-Original-Sender: php-lists@koalephant.com X-Host-Fingerprint: 206.123.115.54 mail1.25mail.st Received: from [206.123.115.54] ([206.123.115.54:54510] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C7/94-28573-33574F95 for ; Sat, 28 Oct 2017 08:16:52 -0400 Received: from [10.0.1.22] (unknown [49.48.245.138]) by mail1.25mail.st (Postfix) with ESMTPSA id 57A2960423; Sat, 28 Oct 2017 12:16:39 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-49F5EABB-D2C7-4524-860B-66F93645DA91 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Sat, 28 Oct 2017 19:16:37 +0700 Cc: Nikita Popov , Christopher Jones , PHP Internals Content-Transfer-Encoding: 7bit Message-ID: <500F9910-78B9-4575-856A-94B4347031FE@koalephant.com> References: <0ac37ce7-62f4-7b1c-5b3d-2d2f45190f07@oracle.com> <4BD31E87-540B-42A3-9823-9FAFD21EEF0A@koalephant.com> To: Thomas Punt Subject: Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail-49F5EABB-D2C7-4524-860B-66F93645DA91 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 28 Oct 2017, at 18:17, Thomas Punt wrote: >=20 > Hi Stephen, >=20 > > I disagree. To me this change would simply mean that the literal exact w= hite-space string preceding the end marker is removed as a prefix from all l= ines. > > > > So if you have an end marker intended by two tab characters, but all the= =E2=80=98content=E2=80=99 lines of the heredoc are indented by 8 spaces, no= thing is removed. >=20 > So let's say the ending marker is indented with [space][tab][space] and th= e body is indented with [tab][space][tab], by your logic, a [space] and a [t= ab] should be removed from the body's indentation? Or nothing at all? >=20 > The problem with such rules is that they bring more complication to the im= plementation when it comes down to the finer details. It is far better to si= mply disallow such nonsense to begin with. >=20 > A nice benefit of this (choosing a stricter approach to begin with) is tha= t, should we see advantages to bringing more leniency to the current semanti= cs (such as enabling the mixture of tabs and spaces), then we can enable thi= s later without causing any new BC breaks. Whereas if we introduce a really l= oose-style syntax to begin with, then we cannot make it stricter later on wi= thout introducing new BC breaks. >=20 > -Tom Hi Tom=20 In your scenario, nothing at all would be removed. I'd imagine an exact subs= tring anchored to the start-of-line is what's matched for any replacement. Strict removal like that is the only thing I can see that makes sense - any c= onversion is likely to lead to developer surprise. Cheers Stephen= --Apple-Mail-49F5EABB-D2C7-4524-860B-66F93645DA91--