> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution > <swift-evolution@swift.org>: > > I don't think I would use that. I don't find the aesthetics pleasant. > I would rather comment above the string literal.
It might be useful when many comments would be required where putting them in a bunch above the literal would make it difficult to properly correlate them with the respective pieces of the string. > > Would the escape character cause the newline for the line to be ignored > thereby continuing the string on the next line? Yes. The semantics of the backslash should not change, its presence just opens the room for placing a comment. To get a newline you would have to write \n\ let myString = "““ text text\n\ // comment text text ““" -Thorsten > > > > On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> One last pitch, can we allow comments in multi-line strings if the string is >> broken up by a backslash? >> >> >> let myString = """ >> text text >> text text text \ // Comment allowed in the current line here, but not in >> the line above it >> text text text \ /* this type of comment is fine too */ >> text text\// notice whitespace can be ignored >> """ >> You might have some interpolation and want to comment around it. >> >> let foo = """ >> bar bar bar >> bar \(x) bar\ // `x` does some magic >> """ >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 12. April 2017 um 12:48:57, Adrian Zubarev >> (adrian.zuba...@devandartist.com <mailto:adrian.zuba...@devandartist.com>) >> schrieb: >> >>> Actually I’m fine with such a compromise. Such a model has everything we’ve >>> asked for, it’s easy, it has both leading and trailing precision and >>> implicit new lines where needed. >>> >>> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution >>> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: >>> >>>> On 12.04.2017 13:16, Thorsten Seitz via swift-evolution wrote: >>>> >> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution >>>> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>>: >>>> >> >>>> >> Great explanation thank you Brent. I’m convinced about the closing >>>> >> delimiter now. =) >>>> >> >>>> >> ------------------------------------------------------------------------------------- >>>> >> >>>> >> If I understood correctly what Xiaodi Wu meant in his reply, then we >>>> >> could simplify >>>> >> the whole multi-line string literal and also remove the need of >>>> >> disabling the >>>> >> stripping algorithm. >>>> >> >>>> >> We should ban these examples completely: >>>> >> >>>> >> |"""Hello·world!"""| >>>> >> >>>> > >>>> > Being able to use ""“ for single line strings containing lots of " is >>>> > useful in >>>> > itself and explained in the motivational section of the proposal: >>>> > "Tripled string literals can also do double duty as a syntax for >>>> > handling short >>>> > string literals with many internal quotation marks“ >>>> > >>>> > -Thorsten >>>> >>>> Yes, I also think the single line string can be very useful and we should >>>> not >>>> disallow it. >>>> >>>> But I agree that we should disallow multi-line cases when we have text on >>>> the same >>>> line with leading or trailing """ because this complicates the mental >>>> modal and adds >>>> confusion points. >>>> >>>> I.e. I suggest to allow only two forms: >>>> 1. Single line: """this is "just" text""" (no line end will be inserted) >>>> 2. Multiline, where leading and trailing """ has no text after/before them >>>> and *all* >>>> the text is in lines *between* triple quotes: >>>> """ >>>> first line >>>> second line >>>> """ >>>> >>>> One can use backslash at the line end to emulate all other needed cases. >>>> Like: >>>> >>>> """ >>>> first line \ >>>> second line\ >>>> """ >>>> >>>> will produce "first line second line" >>>> >>>> > >>>> >> |"""Hello↵ world!""" | >>>> >> |"""Hello↵ world!↵ """ | >>>> >> |"""↵ Hello↵ world!""" | >>>> >> >>>> >> Instead an empty multi-line string literal would look like this: >>>> >> >>>> >> |"""↵ """ | >>>> >> >>>> >> To fix the above example you’d need to write it like this: >>>> >> >>>> >> |"""↵ Hello·world!\↵ """ | >>>> >> |"""↵ Hello↵ world!\↵ """ | >>>> >> >>>> >> * Each line in between the delimiters would add implicit new lines if >>>> >> not >>>> >> disabled by a backslash. >>>> >> * The trailing precision is also handled by the backslash. >>>> >> * The indent is handled by the closing delimiter. >>>> >> * It’s easier to learn/teach. >>>> >> * It’s easier to read, because most of the time the line where the >>>> >> starting >>>> >> delimiter is, is filled with some other code. >>>> >> >>>> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ | >>>> >> >>>> >> Now that would be a true multi-line string literal which needs at least >>>> >> two lines >>>> >> of code. If you’d need a single line literal,|""|is the obvious pick. >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Adrian Zubarev >>>> >> Sent with Airmail >>>> >> >>>> >> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon >>>> >> (br...@architechies.com <mailto:br...@architechies.com> >>>> >> <mailto:br...@architechies.com <mailto:br...@architechies.com>>) >>>> >> schrieb: >>>> >> >>>> >>> >>>> >>>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution >>>> >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> >>>> <mailto:swift-evolution@swift.org >>>> >>>> <mailto:swift-evolution@swift.org>>> wrote: >>>> >>>> >>>> >>>> That’s also the example that kept me thinking for a while. >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> Overall the proposal is a great compromise to some issues I had with >>>> >>>> the first >>>> >>>> version. However I have a few more questions: >>>> >>>> >>>> >>>> * Why can’t we make it consistent and let the compiler add a new line >>>> >>>> after the >>>> >>>> starting delimiter. >>>> >>>> >>>> >>>> | >>>> let string = """↵ Swift↵ """ // result ↵Swift↵ | >>>> >>>> >>>> >>>> If one would would the behavior from the proposal it’s really easy to >>>> >>>> add a >>>> >>>> backslash after the starting delimiter. >>>> >>>> >>>> >>>> | >>>> let string = """\↵ Swift\↵ """ // result Swift | >>>> >>>> >>>> >>>> This would be consistent and less confusing to learn. >>>> >>>> >>>> >>> That would mean that code like this: >>>> >>> >>>> >>> print(""" >>>> >>> A whole bunch of >>>> >>> multiline text >>>> >>> """) >>>> >>> print(""" >>>> >>> A whole bunch more >>>> >>> multiline text >>>> >>> """) >>>> >>> >>>> >>> Will print (with - to indicate blank lines): >>>> >>> >>>> >>> - >>>> >>> A whole bunch of >>>> >>> multiline text >>>> >>> - >>>> >>> - >>>> >>> A whole bunch more >>>> >>> multiline text >>>> >>> - >>>> >>> >>>> >>> This is, to a first approximation, never what you actually want the >>>> >>> computer to do. >>>> >>>> >>>> >>>> * Can’t we make the indent algorithm work like this instead? >>>> >>>> >>>> >>>> |let string = """\↵ ····<tag>↵ ······content text↵ ····</tag>""" // >>>> >>>> Indent starts >>>> >>>> with the first non space character // result <tag>↵ ··content text↵ >>>> >>>> </tag> | >>>> >>>> >>>> >>>> The line where the closing delimiter is trims all space chapters and >>>> >>>> the indent >>>> >>>> for the whole multi-line string is starting at the point where the >>>> >>>> first >>>> >>>> non-space chapters is in that line. >>>> >>>> >>>> >>> We could; I discuss that briefly in the very last section, on >>>> >>> alternatives to the >>>> >>> indentation stripping we specify: >>>> >>> >>>> >>> • Stripping indentation to match the depth of the least indented line: >>>> >>> Instead of >>>> >>> removing indentation to match the end delimiter, you remove >>>> >>> indentation to match >>>> >>> the least indented line of the string itself. The issue here is that, >>>> >>> if all lines >>>> >>> in a string should be indented, you can't use indentation stripping. >>>> >>> Ruby 2.3 does >>>> >>> this with its heredocs, and Python's dedent function also implements >>>> >>> this behavior. >>>> >>> >>>> >>> That doesn't quite capture the entire breadth of the problem with this >>>> >>> algorithm, >>>> >>> though. What you'd like to do is say, "all of these lines are indented >>>> >>> four >>>> >>> columns, so we should remove four columns of indentation from each >>>> >>> line". But you >>>> >>> don't have columns; you have tabs and spaces, and they're incomparable >>>> >>> because the >>>> >>> compiler can't know what tab stops you set. So we'd end up calculating >>>> >>> a common >>>> >>> prefix of whitespace for all lines and removing that. But that means, >>>> >>> when someone >>>> >>> mixes tabs and spaces accidentally, you end up stripping an amount of >>>> >>> indentation >>>> >>> that is unrelated to anything visible in your code. We could perhaps >>>> >>> emit a >>>> >>> warning in some suspicious circumstances (like "every line has >>>> >>> whitespace just >>>> >>> past the end of indentation, but some use tabs and others use >>>> >>> spaces"), but if we >>>> >>> do, we can't know which one is supposed to be correct. With the >>>> >>> proposed design, >>>> >>> we know what's correct—the last line—and any deviation from it can be >>>> >>> flagged *at >>>> >>> the particular line which doesn't match our expectation*. >>>> >>> >>>> >>> Even without the tabs and spaces issue, consider the case where you >>>> >>> accidentally >>>> >>> don't indent a line far enough. With your algorithm, that's >>>> >>> indistinguishable from >>>> >>> wanting the other lines to be indented more than that one, so we >>>> >>> generate a result >>>> >>> you don't want and we don't (can't!) emit a warning to point out the >>>> >>> mistake. With >>>> >>> the proposed algorithm, we can notice there's an error and point to >>>> >>> the line at fault. >>>> >>> >>>> >>> Having the closing delimiter always be on its own line and using it to >>>> >>> decide how >>>> >>> much whitespace to strip is better because it gives the compiler a >>>> >>> firm baseline >>>> >>> to work from. That means it can tell you what's wrong and where, >>>> >>> instead of doing >>>> >>> the dumb computer thing and computing a result that's technically >>>> >>> correct but useless. >>>> >>>> >>>> >>>> PS: If we’d get this feature in Swift, it would be nice if Xcode and >>>> >>>> other IDEs >>>> >>>> which supports Swift could show space characters that are inside a >>>> >>>> string literal >>>> >>>> (not other space character <- which is already supported), so it >>>> >>>> would be easier >>>> >>>> to tell what’s part of the string and what is not. >>>> >>>> >>>> >>> That would be very nice indeed. The prototype's tokenizer simply >>>> >>> concatenates >>>> >>> together and computes the string literal's contents after whitespace >>>> >>> stripping, >>>> >>> but in principle, I think it could probably preserve enough >>>> >>> information to tell >>>> >>> SourceKit where the indentation ends and the literal content begins. >>>> >>> (The >>>> >>> prototype is John's department, though, not mine.) Xcode would then >>>> >>> have to do >>>> >>> something with that information, though, and swift-evolution can't >>>> >>> make the Xcode >>>> >>> team do so. But I'd love to see a faint reddish background behind >>>> >>> tripled string >>>> >>> literal content or a vertical line at the indentation boundary. >>>> >>> >>>> >>> In the meantime, this design *does* provide an unambiguous indicator >>>> >>> of how much >>>> >>> whitespace will be trimmed: however much is to the left of the closing >>>> >>> delimiter. >>>> >>> You just have to imagine the line extending upwards from there. I >>>> >>> think that's an >>>> >>> important thing to have. >>>> >>> >>>> >>> -- >>>> >>> Brent Royal-Gordon >>>> >>> Architechies >>>> >>> >>>> >> >>>> >> _______________________________________________ >>>> >> swift-evolution mailing list >>>> >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> >> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> > >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution