[swift-evolution] [Review] SE-0168: Multi-Line String Literals
adrian.zubarev at devandartist.com
Tue Apr 11 10:08:40 CDT 2017
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 = """↵
If one would would the behavior from the proposal it’s really easy to add a backslash after the starting delimiter.
let string = """\↵
This would be consistent and less confusing to learn.
Can’t we make the indent algorithm work like this instead?
let string = """\↵
····</tag>""" // Indent starts with the first non space character
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.
What do you think?
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.
Sent with Airmail
Am 11. April 2017 um 16:33:28, Vladimir.S via swift-evolution (swift-evolution at swift.org) schrieb:
On 11.04.2017 16:35, John Holdsworth via swift-evolution wrote:
> 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:
Thank you for the detailed proposal.
FWIW, in general I support it, but have two objections/questions:
1. "Tripled string literals support backslash escapes and interpolation as normal,
except that you can also place a backslash immediately before a newline. This
indicates that the newline is merely for code formatting and should not be present in
the resulting string:"
- I think this a confusion point which should not be in this proposal. Currently in
"normal" strings we just can't have single backlash as it will generate "invalid
escape sequence in literal" warning.
Is this feature worth the added complexity? I'm not sure currently.
2. Seems like a mistake:
"Multi-line string with indentation stripping prevented by whitespace before leading
Creates a string with:
I believe it should be just:
> 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
> 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.
>> On 10 Apr 2017, at 12:09, Thorsten Seitz <tseitz42 at icloud.com
>> <mailto:tseitz42 at icloud.com>> wrote:
>>> Am 09.04.2017 um 18:29 schrieb John Holdsworth <mac at johnholdsworth.com
>>> <mailto:mac at 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?
>>> 2 ) Is “””long strings””” the way to go subject to a discussion about the precise
>>> 3) Is the “magic" leading whitespace removal a good idea to support indentation.
>>> 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 ""“).
>>> 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
>>> <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 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
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> What is your evaluation of the proposal?
>>>> 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
>>>> This should be stated explicitly in the proposal.
>>>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>>>> Does this proposal fit well with the feel and direction of Swift?
>>>>> 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.
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
swift-evolution mailing list
swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution