Daniel Duan Sent from my iPhone
> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > <[email protected]> wrote: > > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal from last year. That was my mistake. > > Second up, apologies if the proposal is rather vague on details. In some > sense this was intentional as I didn’t want to get too bogged down in > specifics (and not at all to do with my limitations as a technical writer!) > > I guess we need to build up consensus more slowly by asking the following > questions separately so it can be resubmitted rather than giving a binary > +/-1 on the proposal as it stands. > > 1) Does Swift need multi-line string literals? > 2 ) Is “””long strings””” the way to go subject to a discussion about the > precise delimiter > 3) Is the “magic" leading whitespace removal a good idea to support > indentation. > 4) Does the proposal contain sufficient detail to be discussed/implemented > > My answer to 1) is obviously yes and I think the discussion has come out > about 50/50 so far so lets persevere... > > Trying to fie down 2), a “””long string””” or @“long string”@ or _”long > string”_ or #”long string”# is a string literal inside a new delimiter. It > would be processed exactly as it would a normal string including escapes and > interpolation except the string can include unescaped “ or “" and newlines. > Also, a \ at the end of the line would mean that particular newline is not > included in the string. > > For me, the goals of a long string are that it should be able to pasted in > (almost) without modification from a text source and that syntax highlighting > would work for the widest possible range of text editors and github. “””long > string””” is just a trick Python uses to satisfy the second goal (for example > this gist) but highlighting also works for asymmetric delimiters such as > @“long string”@ which avoid potential problems with “inversion”. Heredoc or a > Swifty #equivalent does not satisfy this second goal at all well and IMHO it > should be excluded. It would also be significantly more difficult to > integrate into the Swift compiler. > > Looking at 3) which is underspecified in the proposal perhaps, I’d consider > it a “feature" but I can see it would be too magical for some. To specify it > more you could say: if there is only whitespace between the last newline and > the end of a multiline literal this whitespace will be stripped from all > lines in the literal. If lines do not start with this exact sequence of > whitespace a warning is emitted. In addition, if the first character in the > literal is a newline it will be removed. This operation could be made > explicit e.g. #trimLeft(“”"a literal""") I'm a enthusiastic supporter for this idea. In a proposal, specificity is a virtue. The algorithm Brent described in his last post is precisely how I imagined this work. It's precise and succinct. I'd consider including it verbatim in the proposal :) > > Perhaps we can find common ground on 1) and 2) and even 3) with a view to > resubmitting if there is time. Seems mostly like we just need to discuss the > delimiter further and decide whether the indent trimming is a bug or a > feature to keep moving and not let another year slip by. > > With respect to 4) I’m updating > https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > as the proposal is discussed to fill in some of the gaps & I’ve prepared a > toolchain for Swift 3 if you want to try an implementation out > >>> On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution >>> <[email protected]> wrote: >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md >> >>> What is your evaluation of the proposal? >> >> +1 >> >> My foremost expectation from multiline string literals is to be able to copy >> and paste multiline string literals without having to fiddle with escape >> marks or leading and trailing quotes or continuation characters. This is >> exactly what the proposal provides and makes it easy to embed SQL, for >> example (using SQL parameters and not string interpolation of course ;-) >> >> The chosen deindentation rules seem very pragmatic and useful to me. >> >> Additional features for multiline string literals can be added easily later. >> >> I would expect multiline string literals to use the same newline character >> as "\n“ does, regardless of the newline character actually used in the file. >> Furthermore all normal escapes, e.g. \n, \t etc. should probably be >> available as well. >> This should be stated explicitly in the proposal. >> >>> Is the problem being addressed significant enough to warrant a change to >>> Swift? >> >> Yes. >> >>> Does this proposal fit well with the feel and direction of Swift? >> >> Yes. >> >>> If you have used other languages or libraries with a similar feature, how >>> do you feel that this proposal compares to those? >> >> For setting the ground it compares favourably. >> >>> How much effort did you put into your review? A glance, a quick reading, or >>> an in-depth study? >> >> Followed most discussions, read the proposal. >> >> -Thorsten >> >> _______________________________________________ >> 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
