> On 6 May 2016, at 20:09, Tyler Cloutier <[email protected]> wrote: > >> >> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon <[email protected] >> <mailto:[email protected]>> wrote: >> >>> As far as mixed whitespace, I think the only sane thing to do would be to >>> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >>> whitespace would be a syntax error. All lines in the string would need to >>> use tabs or all lines use spaces, you could not have one line with tabs and >>> another with spaces. This would keep the compiler out of the business of >>> making any assumptions or guesses, would not be a problem often, and would >>> be very easy to fix if it ever happens accidentally. >> >> The sane thing to do would be to require every line be prefixed with >> *exactly* the same sequence of characters as the closing delimiter line. >> Anything else (except perhaps a completely blank line, to permit whitespace >> trimming) would be a syntax error. >> > > Yes, this I think would be the way to do it.
This is implemented this in today’s prototype toolchain (as a warning) http://johnholdsworth.com/swift-LOCAL-2016-05-06-a-osx.tar.gz <http://johnholdsworth.com/swift-LOCAL-2016-05-06-a-osx.tar.gz> > Heredocs look like they would be harder to parse than the alternative syntax, > no? I’ve had a go at parsing HEREDOC (why does autocorrect always change this to HERETIC!) It wasn’t as difficult as I’d expected once you comment out a few well meaning asserts in the compiler. To keep lexing happy there are two variants <<“HEREDOC” and <<‘HEREDOC’. assert( (<<"XML" + <<"XML") == (xml + xml) ) <?xml version="1.0"?> <catalog> <book id="bk101" empty=""> <author>\(author)</author> <title>XML Developer's Guide</title> <genre>Computer</genre> <price>44.95</price> <publish_date>2000-10-01</publish_date> <description>An in-depth look at creating applications with XML.</description> </book> </catalog> XML <?xml version="1.0"?> <catalog> <book id="bk101" empty=""> <author>\(author)</author> <title>XML Developer's Guide</title> <genre>Computer</genre> <price>44.95</price> <publish_date>2000-10-01</publish_date> <description>An in-depth look at creating applications with XML.</description> </book> </catalog> XML Its a credit to it's authors that Xcode and the remainder of the toolchain cope with this remarkably well now that tokens arrive out of order. The weird colouring is an artefact I’ve not been able to resolve. The changes are here: https://github.com/apple/swift/pull/2275 <https://github.com/apple/swift/pull/2275>, and amount to an additional 60 lines of by no means bullet proof code. The total changes for multi-line literals are now 10% of the Swift lib/Parse/Lexer.cpp. >> Simplicity is good, but I really like the code reading benefits of heredocs. >> Your code is your code and your text is your text. The interface between >> them is a bit funky, but within their separate worlds, they're both pretty >> nice. >> > > I would support having both. I think they have sufficiently different use > cases and tradeoffs to warrant two solutions. It is also nice that if > implementing both were the way to go, continuation quotes could be added to > Swift 3, and heredoc could come later if necessary. I agree, I think we should prepare a joint proposal with all three syntaxes to get consensus. John
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
