[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Adrian Zubarev]

I think it would be good to clarify that there are two similar things we discuss in this proposal.

This proposal is about a [(multi-line string) literal].

And there is also the [multi-line (string literal)].

These are two different things because (1) does add explicit escaping for some characters, where (2) is the current string literal extended for multilines.

As I already mentioned in my previous post, personally I’m in favor of (2) and the existence of (2) raises the question if we need (1) for implicit escaping at all, which I personally like to compare with laziness.

The existence of (2) is easier from the writers perspective, because if you decide at some point to break up your string into multi lines, the string itself won’t be altered because there is no implicit character added to the string, and indent would work as you’d expect it to work. If one would need more precision there would exist leading and trailing precision characters.

However, I think it might be really good compromise, at least to me, as someone mentioned in this review, that we could add a backslash to the proposed (1) [(multi-line string) literal] to prevent implicit new lines and at the same time add trailing precision.

Final words, if I had to choose between (1) and (2), I’d go with (2), because I don’t like the optimization magic that happens behind the scene and would prefer a concrete model for a string literal.



-- 
Adrian Zubarev
Sent with Airmail

Am 10. April 2017 um 04:44:15, Brent Royal-Gordon via swift-evolution (swift-evolution at swift.org) schrieb:

On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution <swift-evolution at swift.org> wrote:

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.

Honestly, I think this is a little premature. If I had to summarize this thread, I think what I'm seeing is:

1. We wish the proposal were more specific on a few points, like the de-indenting algorithm.

2. We have lots of different pet syntaxes and preferences.

3. But most of us are still in favor of accepting the proposal.

To back up that last point, I ran through the thread and tried to quickly figure out what everyone was thinking. These people seem to be opposed to the proposal: 

1. Haravikk doesn't like the de-indenting and seems iffy on multiline strings in general.
2. David Waite wants a suite of different, orthogonal string literal features to get enough flexibility.
3. Félix Cloutier is worried that supporting interpolation makes this feature a powerful footgun.
4. Adrian Zubarev wants to extend single-quoted string literals instead of developing a second syntax.

These people want the proposal to be more specific, but appear to be in favor as long as the missing details don't reveal problems:

1. Greg Parker (maybe?)
2. Xiaodi Wu
3. Gwendel Roué

And these people all seem basically positive, though sometimes with reservations or bikeshedding suggestions:

1. Me
2. Tony Allevato
3. David Hart
4. Daniel Duan
5. Ricardo Parada
6. Kevin Nattinger
7. Víctor Pimentel Rodríguez
8. Jarod Long (I think)
9. Ben Cohen
10. Thorsten Seitz
11. Howard Lovatt
12. T.J. Usiyan

Evolution reviews are not referenda, but I think it's fair to say that the sentiment is mostly positive.

(And if the core team does say they like the approach but want clarifications, I'd be happy to pitch in and earn the co-author credit!)

-- 
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/656032d0/attachment.html>