On Tue, Apr 11, 2017 at 7:50 PM, Xiaodi Wu <[email protected]> wrote:
> On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution < > [email protected]> wrote: > >> >> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution < >> [email protected]> 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. >> > > Brent, excellent job revising the proposal text. My question for you and > the other authors is the other way around: what is the rationale behind > only stripping the leading newline and not the trailing newline? While in > many cases a trailing newline is not harmful or even beneficial, if you > trim the one, wouldn't it make sense to trim the other? Wouldn't it make > the rules easier to explain to users too? For instance: > > ''' > Hello, world! > ''' > > could instead be a one-line string "Hello, world!" > > And those who need the trailing newline can trivially insist on it: > > ''' > Hello, world! > > ''' > I should add, the motivation for proposing this revision to the rules is that it would make it easy for a user to make use of the de-indenting feature of the trailing ''' without opting into a trailing newline by default. > >> - 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
