Same here. IMHO, there needs to be a version of multi line strings that's doesn't require to prefix a token on each line.
> On 30 Apr 2016, at 09:20, Daniel Phillips via swift-evolution > <[email protected]> wrote: > > Sorry for any extra noise here. I've read the 58 emails in this thread and I > just wanted to chime in my support for Dave here. > > I think a multiline string literal implementation along the lines of Python > is a no brainer. > > In particular when I've needed and wanted multiline string literals it has > almost always been when I've wanted to embed text from somewhere external (a > text file for example, or string contents of a JSON file as part of unit > testing). > > Needing to append a token at the beginning of each line of my text would make > multiline string literals considerably less productive for myself. > > Just thought I'd chime in with that. Sorry again for the extra noise. > > Regards, > Daniel > >> On 26 Apr 2016, at 10:55 pm, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >>> on Sun Apr 24 2016, John Holdsworth <[email protected]> wrote: >>> >>> To audition Xcode using the following multi-line syntax: >>> >>> let 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> >>> "" >>> print(xml) >>> >>> You can install: >>> http://johnholdsworth.com/swift-LOCAL-2016-04-25-a-osx.tar.gz >> >> Personally, I don't like that this syntax requires the moral equivalent >> of a continuation character. It means I need to run a regex >> search/replace over my text after I paste it between quotation marks. >> >>> On 24 Apr 2016, at 23:35, Chris Lattner <[email protected]> wrote: >>> >>> On Apr 23, 2016, at 2:08 PM, Brent Royal-Gordon via swift-evolution >>> <[email protected]> wrote: >>> >>> I’m trying to avoid more advanced features such as the handling of >>> indenting which >>> for me complicates something that if kept simple can be documented >>> very easily. >>> >>> I don't think you can tackle multiline strings without worrying about >>> indenting. Indentation may fundamentally change the approach you >>> choose. >>> >>> I agree with this and almost every point you make in your email (and your >>> other subsequent one about one approach maximally general). That said, I >>> wonder if there is a different conclusion that can be reached. I’m going >>> to >>> rearrange your three features a bit: >>> >>> The way I would prefer to tackle these is: >>> >>> * Multiline literals: If the closing quote of a string is not present, >>> look at the next line. If it consists of (optional) indentation >>> followed >>> by a matching opening quote, the string has a newline and then >>> continues >>> after the quote on the next line. (The handling of comments is an open >>> question here.) >>> >>> let xml: String = "<?xml version=\"1.0\"?> >>> "<catalog> >>> "\t<book id=\"bk101\" empty=\"\"> >>> "\t\t<author>\(author)</author> >>> "\t</book> >>> "</catalog>" >>> >>> The cool things about this are that (a) the compiler can tell you >>> really >>> do mean this to be part of the literal and you haven't just forgotten >>> to >>> close the string, and (b) there's no guesswork about how indentation >>> should be handled. The uncool thing is that you need to insert the >>> quote >>> at the beginning of each line, so you can't just blindly paste into a >>> multiline literal. Editors can help make that easier, though—a "paste >>> as >>> string literal" feature would be a nice addition to Xcode, and not >>> just >>> for multiline strings or just for Swift. >>> >>> Yes, I completely agree. This is is awesome, and a nice & simple >>> generalization of our existing syntax. It has obvious behavior even if you >>> encounter it in code without knowing about the feature. >>> >>> * Disabling escapes: If you use single quotes instead of double >>> quotes, >>> backslash escapes are disabled. >>> >>> We need a way to disable escapes, but it seems to me that (since it is >>> orthogonal to the other concerns) that it should not be tied to the >>> “multiple single quotes” syntax. What is your thought on “modifier” prefix >>> characters for string literals? e.g.: >>> >>> let x = e”no \escapes \(processed here” >>> >>> If we supported these, they would be supported with multi-line string >>> literals by putting the modifiers on the first line of the literal, and >>> the >>> multi-line approach above would “just work”. You could introduce several >>> different modifiers, e.g. one that disabled general escapes, but still >>> allowed \(x) for substitution. >>> >>> * Yes, with a number of backslashes matching the number of quotes, >>> which >>> allows you to insert literal \( text: ''' <author>\\\(author)</author> >>> >>> Egads! >>> >>> Notes on alternatives: >>> >>> 1. If you wanted to not provide no-escaping strings, an alternative >>> would be to say that *all* escapes require as many backslashes as >>> there >>> are quotes in the string delimiter. Thus, a newline escape in a `"""` >>> string would be `\\\n`. This would in practice give you the same >>> flexibility to write a literal without worrying (much) about escaping. >>> >>> I’m really not a fan of requiring “stacking” of escapes to re-enable them. >>> This (IMO) just makes it less likely that you’ll run into an edge case. I >>> also don’t like the “fix" being to have to use 5 quotes around your >>> strings : >>> -) >>> >>> 3. It might be useful to make multiline `"` strings trim trailing >>> whitespace and comments like Perl's `/x` regex modifier does. >>> >>> If you have modifier characters already, it is easy to build a small zoo >>> full of these useful beasts. >>> >>> * Alternative delimiters: If a string literal starts with three, or >>> five, or seven, or etc. quotes, that is the delimiter, and fewer >>> quotes >>> than that in a row are simply literal quote marks. Four, six, etc. >>> quotes is a quote mark abutting the end of the literal. >>> >>> let xml: String = """<?xml version="1.0"?> >>> """<catalog> >>> """\t<book id="bk101" empty=""> >>> """\t\t<author>\(author)</author> >>> """\t</book> >>> """</catalog>""" >>> >>> You can't use this syntax to express an empty string, or a string >>> consisting entirely of quote marks, but `""` handles empty strings >>> adequately, and escaping can help with quote marks. (An alternative >>> would be to remove the abutting rule and permit `""""""` to mean >>> "empty >>> string", but abutting quotes seem more useful than long-delimiter >>> empty >>> strings.) >>> >>> I agree that there is a need to support alternative delimiters, but >>> subjectively, I find this to be pretty ugly. It is also a really >>> unfortunate >>> degenerate case for “I just want a large blob of XML” because you’d end up >>> using “"” almost all the time, and you have to use it on every line. >>> >>> For cases like this, I think it would be reasonable to have a “heredoc” >>> like >>> scheme, which does not allow leading indentation, and does work with all >>> the >>> same modifier characters above. I do not have a preference on a particular >>> syntax, and haven’t given it any thought, but this would allow you to do >>> things like: >>> >>> let str = <<EOF >>> <?xml version="1.0"?> >>> <catalog> >>> \t<book id="bk101" empty=""> >>> \t\t<author>\(author)</author> >>> \t</book> >>> </catalog> >>> EOF >>> >>> for example. You could then turn off escaping and other knobs using the >>> modifier character (somehow, it would have to be incorporated into the >>> syntax of course). >>> >>> I generally agree with your down thread remarks about how Swift doesn’t >>> like >>> to have multiple different solutions for the same problem. OTOH, you could >>> look at “” syntax as being analogous to closure exprs, and heredoc syntax >>> as >>> being analogous to nested functions :-) >>> >>> -Chris >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> -- >> Dave >> >> _______________________________________________ >> 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
