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@swift.org) schrieb:

On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution 
<swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to