That’s a great revision, Brent! Thanks a lot! I like it as written but would also be totally fine with Xiaodi’s proposition of stripping the trailing newline by default (requiring an empty line for a trailing newline).
-Thorsten > Am 11.04.2017 um 15:35 schrieb John Holdsworth <[email protected]>: > > I feel discussion on this proposal is nearing general agreement that while > the gist of it > it seems reasonable to many there is also not enough detail in it as > submitted. > > Brent has person-fully stepped in and rewritten the draft to translate it > into a detailed > specification which I’ve updated here: > > 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> > > Perhaps we could use the remaining time on the review to pre-evaluate this > draft should > we get the chance to resubmit with modifications to maximise its chances. Key > questions: > > 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. > > The main change on the revised proposal from the the original submitted is > Thorsten’s > suggestion that Windows line endings in a source file be normalised to \n in > the literal. > > John > >> On 10 Apr 2017, at 12:09, Thorsten Seitz <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> Am 09.04.2017 um 18:29 schrieb John Holdsworth <[email protected] >>> <mailto:[email protected]>>: >>> >>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
