On Apr 27, 2016, at 1:52 AM, Brent Royal-Gordon <br...@architechies.com> wrote: > >> If you agree that these are all orthogonal pieces, then treat them as such: >> I’d suggest that you provide a proposal that just tackles the continuation >> string literals. This seems simple, and possible to get in for Swift 3. > > I've gone ahead and drafted this proposal, with some small extensions and > adjustments. See the "Draft Notes" section for details of what I've changed > and what concerns I have.
Awesome. Some specific suggestions below, but feel free to iterate in a pull request if you prefer that. > > <https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#introduction>Introduction > > In Swift 2.2, the only means to insert a newline into a string literal is the > \n escape. String literals specified in this way are generally ugly and > unreadable. We propose a multiline string feature inspired by English > punctuation which is a straightforward extension of our existing string > literals. > > Swift-evolution thread: multi-line string literals. > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015500.html>I > would suggest - right up front - pointing out that “heredoc” style syntaxes > are another potential solution to this problem, but that they are heavier > weight (and other tradeoffs). This proposal doesn’t attempt to address there > heredoc usecase, but it also doesn’t preclude adding it. It is also > mentioning up front that this is part of multi-part proposal to make string > literals nicer, and point to the “possible future directions” section at the > end. > > <https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#draft-notes>Draft > Notes > > This draft differs from the prototypes being thrown around on the list in > that it specifies that comments should be treated as whitespace, and that > whitespace-only lines in the middle of a multiline string should be ignored. > I'm not sure if this is feasible from a parsing standpoint, and I'd like > feedback from implementers on this point. > White space seems “implementable”, but I’m not sure that it is good. Visually, it would break up the string literal and make it less obviously a unit. Comments on the same line as a string chunk should *not* be split out IMO, in: let s = “fooo // hello world “ nice to know you” the “hello world” text should be included in the literal. I suppose it would be possible to allow comments on whitespace lines, but I don’t see a reason to do that. I’d suggest starting simple, since that could always be added down the road if there was great demand. > This draft also specifies diagnostics which should be included. Feedback on > whether these are good choices would be welcome. > I’d just say that these are suggested diagnostics that can be word smithed later. > I am considering allowing you to put a backslash before the newline to > indicate it should not be included in the literal. In other words, this code: > > print("foo\ > "bar") > Would print "foobar". However, I think this should probably be proposed > separately, because there may be a better way to do it. > I don’t see a reason to do that. Why would this be helpful? > Benefits of continuation quotes > > It would be simpler to not require continuation quotes, > I’d suggest being explicit here: "It would be simpler to not require continuation quotes at the start of subsequent lines, " > > Rules 1 and 2 should treat comments as though they are whitespace; this > allows you to comment out individual lines in a multiline string literal. > (However, commenting out the last line of the string literal will still make > it unterminated, so you don't have a completely free hand in commenting.) > As I mentioned above, I’d suggest keeping the proposal minimal - that makes it more likely to be accepted since you’re removing something that the discussion could rathole on. > Impact on existing code > > Failing to close a string literal before the end of the line is currently a > syntax error, so no valid Swift code should be affected by this change. > I would add a “Potential Future Directions” section here, mention modifier characters, here doc, etc. That will help explain how this proposal fits into your broader plan, and address the question of “ok, your XML example looks a little better, but what’s with all the escaping?!??” :-) > This has several advantages: > > It is simpler. > > It is less offensive to programmers' sensibilities (since there are no > unmatched " characters). > > It does not require that you edit the string literal to insert a continuation > quote in each line. > > Balanced against the advantages, however, is the loss of the improved > diagnostics, code formatting, and visual affordances mentioned in the > "Benefits of continuation quotes" section above. > Just a writing observation, but by bulleting the advantages (and not bulleting the disadvantages) you’re making it look visually like the advantages are stronger or more important than the disadvantages. > > <https://gist.github.com/brentdax/c580bae68990b160645c030b2d0d1a8f#use-a-different-delimiter-for-multiline-strings>Use > a different delimiter for multiline strings > > The initial suggestion was that multiline strings should use a different > delimiter, """, at the beginning and end of the string, with no continuation > characters between. > Personally, I think that “”” could be the compelling heredoc designator we will also need. :-) It would certainly fit elegantly with modifier characters, the same way that “” does. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
