I suppose by pure I mean consistent - treatment of the end of the string
is the same as the treatment of the beginning of the string period.
Practical for me is to do with how you might “want” it to behave. For example
Brent came up with a glitch in previous processing where you had “ inside each
end of the literal.
print(""""hello world"""")
prints
"hello world"
To achieve this I had to doctor the termination logic to do something that isn’t
entirely consistent in treatment of the initial and final internal “ but seemed
what people might expect rather than having to escape it.
I would argue we need something analogous for an initial blank line in the
source
which we definitely want but not necessarily extend this to the closing newline.
Not rigorous in some sense but likely to better suited to most use cases.
> On 12 Apr 2017, at 22:49, Xiaodi Wu <[email protected]> wrote:
>
> Sorry, what do you mean by "pure" or "practical"?
> On Wed, Apr 12, 2017 at 16:41 John Holdsworth <[email protected]
> <mailto:[email protected]>> wrote:
> There isn’t much in it TBH and I could live with either. Option 1 seems to
> have been a regression.
>
> Option 3 is the pure route in one sense but for me Option 2 the more
> practical which I
> was hoping to demonstrate with the example strings. I’d also ague lines
> should be
> complete (have line endings unless escaped) by default in a multiline string.
>
>> On 12 Apr 2017, at 22:31, Xiaodi Wu <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> John, why do you think that option 2 is superior to option 3?
>>
>>
>> On Wed, Apr 12, 2017 at 16:14 John Holdsworth via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>> I think we’re agreeing. Looks like I need to clarify my last post a little.
>> When I included the following strings:
>>
>> let longstring = """\
>> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
>> eiusmod \
>> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
>> minim veniam, \
>> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
>> commodo consequat.\
>> """
>>
>> print( """\
>> Usage: myapp <options>
>>
>> Run myapp to do mything
>>
>> Options:
>> -myoption - an option
>> """ )
>>
>> These were expressed in term of the proposal after last nights changes.
>>
>> By advocating option 2) I’m accepting we should revert back to the following:
>>
>> let longstring = """
>> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
>> eiusmod \
>> tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
>> minim veniam, \
>> quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
>> commodo consequat.\
>> """
>>
>> print( """
>> Usage: myapp <options>
>>
>> Run myapp to do mything
>>
>> Options:
>> -myoption - an option
>> ""” )
>>
>>> 1) Proposal as it stands - no magic removal of leading/training blank
>>> lines.
>>> 2) Removal of a leading blank line when indent stripping is being applied.
>>> 3) Removal of leading blank line and trailing newline when indent stripping
>>> is being applied.
>>
>>
>> Also, note: the toolchain does not seem to work at all with playgrounds.
>> I’ve been using small test apps.
>>
>>> On 12 Apr 2017, at 21:06, Adrian Zubarev via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Exactly, I feel like we found a Swifty version of a multi-line string
>>> literal. :)
>>>
>>>
>>>
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 12. April 2017 um 21:58:37, Vladimir.S via swift-evolution
>>> ([email protected] <mailto:[email protected]>) schrieb:
>>>
>>>> this:
>>>> """
>>>> one
>>>> two
>>>> """
>>>> should be just the same as "one\ntwo\n"
>>>>
>>>> If one wants some advanced tuning of line ends, he/she can use a
>>>> backslash, for example
>>>> """
>>>> one
>>>> two\
>>>> """
>>>> should produce "one\ntwo"
>
>>>
>>> _______________________________________________
>>> 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] <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
