Inline Regards (From mobile)
> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >>> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution >>> <[email protected]> wrote: >>> >>> >>>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>>> On 5 May 2016, at 14:17, David Hart <[email protected]> wrote: >>>>> >>>>> >>>> >>>>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> it's not a secret that I'm not a big fan of the proposal. The third draft >>>>> doesn't change this and it's unlikely that any future draft will, because >>>>> for me, the problem are the continuation quotes, and for Brent it seems >>>>> like they are a must-have-feature (correct me if I'm wrong.) >>>> >>>> I agree with all you said. I’m fairly sure I would never vote for Brent’s >>>> proposal simply because of the existence of continuation quotes, no matter >>>> the amount of reasoning behind it. They are simply too unwieldy, >>>> cumbersome and unfriendly to modification. >>>> >>>> I could see either your proposal, or your proposal without the HERE_DOCs >>>> but using Tyler’s/Scala’s .stripMargin. Do you think you could start a >>>> formal proposal? >>> >>> >>> Adapting the original proposal if you’re not a fan of continuation quotes.. >>> >>> It’s possible to have a multiline “””python””” multi-line string but tidily >>> indented. >>> As suggested earlier in this thread the lexer can strip the margin on the >>> basis of >>> the whitespace before the closing quote as per Perl6 (This could be a >>> modifier “I” >>> but might as well be the default TBH.) Would this be the best of both >>> worlds? >>> >>> assert( xml == i""" >>> <?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> >>> ""” ) >>> >>> Other modifiers can also be applied such as “no-escapes" >>> >>> assert( xml != ei"""<?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> >>> """ ) >>> >>> I’d hope this would satisfy any need for <<HERE/<<‘HERE’ style constructs. >>> >>> Or you could support both continuation and indented python style: >>> http://johnholdsworth.com/swift-LOCAL-2016-05-05-a-osx.tar.gz >>> >>> John >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> I’m of the opinion that either of these are reasonable solutions, and both >> offer different tradeoffs. I’m probably partial to the continuation quotes, >> because I don’t want to be guessing about what is going to end up being in >> my string and what won’t. >> >>> assert( xml != ei"""<?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> >>> ""” ) >> >> For example, is there a new line after </catalog>? >> How would the indenting work if it were immediately followed by triple >> quotes: </catalog>””” >> I would really like the first line to be lined up with the rest of the xml. >> Is that going to introduce a newline into the top of the string? >> >> Could we just enforce that no characters on the lines of the triple quotes >> would be included in the string, very much like the heredoc syntax? >> >> assert( xml != ei"”” The text I’m typing here would cause a compiler >> error. >> <?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> >> same here ""” ) >> >> Then it’s very clear what the whitespace stripping will do. But what about >> mixed tab vs whitespace? What is the behavior in that case? > > > I’m jumping into this thread late and have only followed bits of it so I > apologize if I’m repeating anything. > > I really like the idea of having leading space stripped automatically without > requiring the continuation quotes. I have done my share of leading space > stripping in the past when working with heredocs. It’s not that big a deal > but it would be better to have the language take care of it for us. > > I like the idea of banning any characters on the same line as the triple > quotes (not just omitting them but actually making it a syntax error to > include them). > > 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. Upon first consideration, this does not strike me as realistic considering how we are talking about invisible character (requiring editor configuration to be materialisable) and how widely diverse the opinions which to use are, leading to all sorts of combinations in existing source code. > 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. > > -Matthew > >> >> Tyler >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
