> On 28 Oct 2017, at 18:17, Thomas Punt <tp...@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
