> Am 12.04.2017 um 14:56 schrieb Xiaodi Wu <xiaodi...@gmail.com>: > > Sure, but keep in mind you're ultimately presenting a long string to the > user. Chances are if it needs commenting to the reader of the code, it needs > commenting to the reader of the string (which could be code itself, whether a > SQL query or something else).
Good point. > Can you give a use case where essentially you need two-tiered comments like > this? Nope, just thought that Adrian’s idea seemed useful and not detrimental. Actually I’m fine with or without comments. -Thorsten > > > On Wed, Apr 12, 2017 at 07:47 Thorsten Seitz via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution >> <swift-evolution@swift.org <mailto: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 <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
