> On 16 May 2017, at 15:01, Gwendal Roué <[email protected]> wrote:
>
> Xiaodi Wu, your opposition has been recorded. You don't buy the Motivation
> section. Other people here do, definitely.
>
>> Divorce the """ delimiter from the multi-line syntax and have them only
>> support unescaped double-quotes
>
> This means support for:
>
> let x = "
> foo
> bar
> "
>
> This one is unexpected, and not requested by many users. Does it bring much?
>
> I wonder whether this addition was introduced in order to make the proposal
> as consistent as possible, and prevent some criticisms. It has proven
> pointless. I suggest forgetting about pleasing people who don't want to be
> pleased, and to reconsider this "divorce" section. Consistency is not the
> main point. The main point is UX. This means easing the daily life of code
> writers, and easing the daily life of code readers (this involves being
> careful which text editors and code prettyfiers are unable to handle the
> proposal).
Well, one of the issues I have with the status-quo is that ""” has two meanings
(support for “ without escaping and multi-line support), which causes
consistency issues when you want to support “"” one-liners. I prefer a model
where features can be orthogonally composed: hence “”” for escaping, and
newlines around delimiters to signify multi-lines. Support for multi-lines with
“ delimiters is a natural consequence of that model: so why disallow it?
>> Support escaping newlines in multi-line strings with a trailing \
>
> Great. That's the main request, unless I'm misled: split long literals
> accross multiple lines.
>
> Now that Xiaodi Wu has found them, the core team questions about the trailing
> backslash should be addressed in more details.
Sure:
acknowledge[] that single-line triple quoted strings have other uses in other
languages, [...] but supporting that alongside the indentation-stripping
behavior leads to a lot of subtlety, and there could be other solutions to the
escaping problem down the line, such as raw strings.
I’m not sure what subtleties they are referring to, so I don’t know how to
address those fears. And I’m not convinced raw strings are the right solution
because I’d like to retain escaping and string interpolation even in those
one-liners. Raw strings are interesting, I just don’t see them as a solution
for triple-quoted one-liners.
[d]iscussion on the list raised the idea of allowing a line to end with \ to
"escape" the newline and elide it from the value of the literal.' They
deliberately rejected that feature for Swift 4, reasoning that '[they] had
concerns about only allowing that inside multi-line literals and felt that that
could also be considered later as an additive feature.
This last one confused me. In what else than multi-line literals could we
escape newlines? Be definition, if you don’t escape it, it’s a newline and your
are by definition in a multi-line literal.
>> Adopt the C/Objective-C syntax that concatenates single-line strings
>
> A battle-tested solution. Doesn't it look redundant with both the "divorce"
> and the trailing backslash?
It may look redundant but I see them supporting two different purposes:
Multi-line strings allow editing and copy/pasting of long strings, containing
newlines, without having to prefix each line with a delimiter (because it does
it’s nice leading whitespace stripping): it’s great for DSLs like SQL where
newlines help readability but has no effect on parsing. But it comes at the
expense of vertical space.
The string concatenation syntax is great for shorter pieces of text where
newlines should not be inserted by default and where vertical space is more
conservative: greater for text messages.
If we did not have that feature, long text messages which need manual wrapping
would look like:
assert(condition, “””
This is my message but after some point I need to go to the \
next line and I need to escape newlines on every line.
“”"
> Last, the proposal contains literals without leading and trailing newlines. I
> thought those were not supported by SE-0168. If this is the case, we need
> more detail here, so that the proposal is rock solid, and the core team
> confident it deserves consideration. A little more work, please :-)
>
> Thanks,
> Gwendal Roué
>
>
>
>> Le 15 mai 2017 à 23:52, Xiaodi Wu via swift-evolution
>> <[email protected]> a écrit :
>>
>> I'm quite sure it means this: As with all parts of Swift, a decision can be
>> re-considered if implementation difficulties are found, or if new insights
>> arise from extended use. Because these features are additive, rejecting them
>> now does not mean that source compatibility requirements would make such
>> re-consideration impossible--if they are to be re-considered in the future.
>> Until such time as a fit justification is found to bring the current
>> decision into question, the decision of the core team is that these proposed
>> features are rejected from inclusion in Swift.
>> On Mon, May 15, 2017 at 16:28 David Hart <[email protected]> wrote:
>>> On 14 May 2017, at 03:55, Xiaodi Wu <[email protected]> wrote:
>>>
>>> On Sat, May 13, 2017 at 1:42 AM, David Hart <[email protected]> wrote:
>>>
>>>> On 12 May 2017, at 23:14, Xiaodi Wu <[email protected]> wrote:
>>>>
>>>> I feel like a broken record: Of the three proposed components of the
>>>> proposed solution, two were amply considered by the community and the core
>>>> team in SE-0168. The decision has already been made _not_ to implement
>>>> these ideas at this time.
>>>
>>> Can you provide me with quote from the Core Team that it should not be
>>> implemented at this time? I have troubles finding it.
>>>
>>>> Significant defects discovered after the fact during implementation or new
>>>> insights after extensive usage can prompt revisiting the decision, but
>>>> that is not the case here: implementation did not require further
>>>> clarification and the feature has only just landed on master. We simply
>>>> cannot revisit topics willy-nilly. The process simply cannot work that
>>>> way: few have the time and energy to offer their fullest consideration the
>>>> first time round, and no one would be willing to do that if it means that
>>>> the same topic will be revisited one month later.
>>>
>>> The concerns summarised in this proposal were only heavily discussed after
>>> the acceptance of multi-line strings. Therefore, there is a great chance
>>> that they were not discussed by the Core Team. We feel obliged to put this
>>> proposal forward to formalise those issues.
>>>
>>>
>>> [1]
>>>
>>> Your draft proposes to '[d]ivorce the `"""` delimiter from [...] multi-line
>>> syntax' in order to allow `"""long strings"""` to be valid syntax.
>>>
>>> SE-0168 proposed 'a single simple syntax for inclusion: """long
>>> strings"""`, explicitly permitting that syntax.
>>>
>>> The core team, after considering SE-0168, deliberately rejected that
>>> feature for Swift 4. They wrote that they 'acknowledge[] that single-line
>>> triple quoted strings have other uses in other languages, [...] but
>>> supporting that alongside the indentation-stripping behavior leads to a lot
>>> of subtlety, and there could be other solutions to the escaping problem
>>> down the line, such as raw strings.' They concluded that: 'If nothing else,
>>> single-line triple quoted strings can be considered later as an additive
>>> feature.'
>>>
>>> [2]
>>>
>>> Your draft proposes to 'support escaping newlines in multi-line strings
>>> with a trailing `\`'.
>>>
>>> The core team, after considering SE-0168, acknowledged that '[d]iscussion
>>> on the list raised the idea of allowing a line to end with \ to "escape"
>>> the newline and elide it from the value of the literal.' They deliberately
>>> rejected that feature for Swift 4, reasoning that '[they] had concerns
>>> about only allowing that inside multi-line literals and felt that that
>>> could also be considered later as an additive feature.'
>>>
>>>
>>> If someone from the Core Team lets us know this is definitely out of scope
>>> for Swift 4, we’ll be happy to bring it back once discussion for Swift 5
>>> starts.
>>>
>>>
>>> Not being on the core team, I can't tell you what's definitely out of
>>> scope, but I'm pretty sure discussing something "down the line" and "later"
>>> don't mean revisiting a topic 22 days after the original proposal is
>>> modified and 16 days after it's implemented, but rather in a future version
>>> of Swift, after users have been able to try and gain experience with the
>>> approved design.
>>
>> Thanks for the references! Indeed, those specific points were discussed but
>> I’m not sure what they mean by "can be considered later as an additive
>> feature”. I’m not so certain it necessarily pushes it back to a future
>> version of Swift. Nonetheless, the other points in the proposal don’t seem
>> to have been discussed.
>>
>>>> On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution
>>>> <[email protected]> wrote:
>>>> Hi swift-evolution,
>>>>
>>>> Adrian Zubarev and I have discussed several issues with string literals
>>>> still unresolved after the multi-line string literals proposals and we
>>>> believe that they are important enough to address for Swift 4. Here is the
>>>> pitch for our proposal.
>>>>
>>>> Please let us know what you think:
>>>>
>>>> https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md
>>>>
>>>> Improve String Literals
>>>>
>>>> • Proposal: SE-XXXX
>>>> • Authors: David Hart, Adrian Zubarev
>>>> • Review Manager: TBD
>>>> • Status: TBD
>>>> Introduction
>>>>
>>>> This proposal builds on top the new features of SE-0168 Multi-Line String
>>>> Literals by widening the use-cases for unescaped double-quotes and
>>>> resolving certain issues around long lines in single and multi-line string
>>>> literals.
>>>>
>>>> Motivation
>>>>
>>>> In Swift 3, String literals have three pain points:
>>>>
>>>> • Strings containing double-quotes
>>>> • Multi-line strings
>>>> • Long single-line strings
>>>> Proposal SE-0168 fixed the two first problems with the same syntax.
>>>> Unfortunately, while an improvement on Swift 3, several problems remain:
>>>>
>>>> • Long single-line strings still require the less than ideal
>>>> concatenation syntax:
>>>> Some project styles (like the Standard Library) mandate a maximum line
>>>> length, requiring long single-line strings to be hard-wrapped. This still
>>>> requires odd solutions:
>>>>
>>>> assert(condition, "This is a long assertion message that requires " +
>>>>
>>>>
>>>> "string concatenation when the project style enforces maximum line " +
>>>>
>>>>
>>>> "lengths")
>>>> • Long lines in a multi-line strings can't be manually wrapped:
>>>> let markdown = """
>>>> # Title
>>>>
>>>> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer
>>>> elementum commodo sem, a congue orci porta sit amet. Duis facilisis, est
>>>> et vehicula congue, turpis dui ultricies nunc, ut elementum quam elit nec
>>>> felis. Integer aliquam id risus nec laoreet. Vivamus vitae odio sit amet
>>>> quam iaculis fermentum nec sed neque.
>>>>
>>>> ## Subtitle
>>>>
>>>> Cras et nibh velit. Praesent eleifend sagittis quam, pellentesque
>>>> lobortis lectus commodo vel. Vivamus suscipit, nulla quis blandit
>>>> ullamcorper, velit neque euismod nibh, nec blandit mi diam molestie ex.
>>>> Cras porttitor, est sed pharetra interdum, ipsum mauris viverra quam, sit
>>>> amet eleifend purus elit sit amet odio.
>>>> """
>>>> • Short strings containing double-quotes have to use the multi-line
>>>> syntax to benefit from unescaped double-quotes:
>>>> print("""
>>>> { "success": false, "error": "Wrong parameter" }
>>>> """)
>>>> Proposed solution
>>>>
>>>> By implementing multi-line string literals and support for unescaped
>>>> double-quotes with the same syntax, SE-0168 has made those features
>>>> unusable on their own. By dissociating them and supporting two extra
>>>> syntax features, we can solve all the above problems:
>>>>
>>>> Divorce the """ delimiter from the multi-line syntax and have them only
>>>> support unescaped double-quotes
>>>>
>>>> The change allows us to express short strings containing double-quotes
>>>> without resorting to the multi-line syntax:
>>>>
>>>> print("""{ "success": false, "error": "Wrong parameter" }""")
>>>> As a consequence, multi-line strings are now only defined by a newline
>>>> following the leading delimiter and the whitespace preceeding the trailing
>>>> delimiter. They gain support for " delimiters, which has the nice
>>>> advantage of saving a few characters in multi-line strings which are known
>>>> to never contain double-quotes:
>>>>
>>>> print("""
>>>> Triple "
>>>> are still valid delimiters
>>>>
>>>> """)
>>>>
>>>> query("
>>>>
>>>> SELECT 'name'
>>>> FROM 'people'
>>>> WHERE age
>>>>> 20
>>>>
>>>>
>>>> ")
>>>> Support escaping newlines in multi-line strings with a trailing \
>>>>
>>>> This change allows hard-wrapping long lines in multi-line strings. They
>>>> also have the added benefit of making trailing white-space at the end of
>>>> source-code lines explicit.
>>>>
>>>> let markdown = """
>>>> # Title
>>>>
>>>> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer \
>>>> elementum commodo sem, a congue orci porta sit amet. Duis facilisis,
>>>> est \
>>>> et vehicula congue, turpis dui ultricies nunc, ut elementum quam elit
>>>> nec \
>>>> felis. Integer aliquam id risus nec laoreet. Vivamus vitae odio sit
>>>> amet \
>>>> quam iaculis fermentum nec sed neque.
>>>>
>>>> ## Subtitle
>>>>
>>>> Cras et nibh velit. Praesent eleifend sagittis quam, pellentesque \
>>>> lobortis lectus commodo vel. Vivamus suscipit, nulla quis blandit \
>>>> ullamcorper, velit neque euismod nibh, nec blandit mi diam molestie \
>>>> ex. Cras porttitor, est sed pharetra interdum, ipsum mauris viverra \
>>>> quam, sit amet eleifend purus elit sit amet odio.
>>>> """
>>>> Adopt the C/Objective-C syntax that concatenates single-line strings
>>>>
>>>> This change will be familiar to C developers and provides a cleaner and
>>>> more performant solution for long single-line strings:
>>>>
>>>> assert(condition, "This is a long assertion message that flows "
>>>>
>>>>
>>>> "from one line to the next without requiring the concatenation "
>>>>
>>>>
>>>> "operator"
>>>> )
>>>>
>>>>
>>>> assert(condition, """This is another "single-line" message that """
>>>>
>>>>
>>>> """supports up to two double-quotes (" and "") without any """
>>>> """escaping""")
>>>> Source compatibility
>>>>
>>>> This feature is purely additive; it has no effect on source compatibility.
>>>>
>>>> Effect on ABI stability
>>>>
>>>> This feature is purely additive; it has no effect on ABI stability.
>>>>
>>>> Effect on API resilience
>>>>
>>>> This feature is purely additive; it has no effect on API resilience.
>>>>
>>>> Alternatives considered
>>>>
>>>> A different syntax for supporting long single-line strings was discussed
>>>> where ending delimiters were replaced with the \escaping character,
>>>> mirroring their use in multi-line strings:
>>>>
>>>> assert(condition, "This is a long assertion message that flows \
>>>> "
>>>> from one line to the next without requiring the concatenation \
>>>>
>>>> "operator"
>>>> )
>>>>
>>>>
>>>> assert(condition, """This is another "single-line" message that \
>>>> """supports up to two double-quotes (" and "") without any \
>>>> """escaping""")
>>>> That syntax saved two characters per line in strings with """ delimiters
>>>> but had several disadvantages:
>>>>
>>>> • It loses the familiarity with C syntax
>>>> • It introduces an asymmetry between the last line and those above
>>>> • It does not do any actual escaping, introducing developer ambiguity
>>>> with their use in multi-line literals
>>>>
>>>> _______________________________________________
>>>> 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
