> Am 09.04.2017 um 18:29 schrieb John Holdsworth <m...@johnholdsworth.com>: > > 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?
Yes. > 2 ) Is “””long strings””” the way to go subject to a discussion about the > precise delimiter Yes. > 3) Is the “magic" leading whitespace removal a good idea to support > indentation. Yes. > 4) Does the proposal contain sufficient detail to be discussed/implemented Thanks for the update! I only have the following issues left: > All other escapes would be processed as before including interpolation, \n > and " You probably meant \“ instead of " here. The proposal should state what kind of newline will be used within a multiline string literal. I already proposed that it should be exactly the same as for \n and not the newline character(s) actually used in the file (e.g. LF+CR or LF or CR), to avoid issues when working on different platforms (Windows, Mac, Linux) and/or using Git’s autocrlf feature. The proposal should give an example how to create a multiline string literal which ends with a newline (AFAIU there should be an empty line before the closing ""“). -Thorsten > > 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 > <https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf#file-multiline-swift-L97>) > 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""") > > 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 > > <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 > <http://johnholdsworth.com/swift-LOCAL-2017-04-09-a-osx.tar.gz> > >> On 9 Apr 2017, at 15:35, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md >>> >>> <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 >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
