Re: [RFC] Flexible Heredoc and Nowdoc Syntaxes

> On 28 Oct 2017, at 18:17, Thomas Punt <tpunt@hotmail.co.uk> wrote: > > Hi Stephen, > > > I disagree. To me this change would simply mean that the literal exact white-space string > > preceding the end marker is removed as a prefix from all lines. > > > > So if you have an end marker intended by two tab characters, but all the ‘content’ > > lines of the heredoc are indented by 8 spaces, nothing is removed. > > So let's say the ending marker is indented with [space][tab][space] and the body is > indented with [tab][space][tab], by your logic, a [space] and a [tab] should be removed from the > body's indentation? Or nothing at all? > > The problem with such rules is that they bring more complication to the implementation when it > comes down to the finer details. It is far better to simply disallow such nonsense to begin with. > > A nice benefit of this (choosing a stricter approach to begin with) is that, should we see > advantages to bringing more leniency to the current semantics (such as enabling the mixture of tabs > and spaces), then we can enable this later without causing any new BC breaks. Whereas if we > introduce a really loose-style syntax to begin with, then we cannot make it stricter later on > without introducing new BC breaks. > > -Tom Hi Tom In your scenario, nothing at all would be removed. I'd imagine an exact substring 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 conversion is likely to lead to developer surprise. Cheers Stephen