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

On 16.04.2017 0:22, Adrian Zubarev via swift-evolution wrote: Hi guys, I am, and also my English is, at my most limit fighting in this conversation. ;-) I would not support, v1 v2 and v3 at all and would wish these options to be completely banned for a nice and simple model, even if all of

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

Hi guys, I am, and also my English is, at my most limit fighting in this conversation. ;-) I would not support, v1 v2 and v3 at all and would wish these options to be completely banned for a nice and simple model, even if all of the options can be implemented and might look OKAY for some

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

> On Apr 15, 2017, at 3:28 PM, Thorsten Seitz wrote: > >> Here is another example: >> >> case .isExprSameType(let from, let to): >> return """checking a value with optional type \(from) \ >>against dynamic type \(to) \ >>

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

> Am 15.04.2017 um 16:46 schrieb Ricardo Parada : > > Reply inline. > > On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution > > wrote: > >> >>> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via

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

Reply inline. On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution > wrote: > >> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution >> >: >> >>

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

> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution > : > > I disagree, the examples you have provided are more complicated than you > might think they are. Before explaining why, I’m going to make things clear > about the ‘two modes’ of the

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

> Am 14.04.2017 um 23:35 schrieb BJ Homer : > > >> Consider these two examples: >> >> let string_1 = """foo""" >> >> >> let string_2 = """ >> foo >> """ >> What’s the intuitive result you’d expect without taking all the long talk >> from the list into account? >>

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

It might really be non-odious, but it’s the correct behavior. It’s the same as you’d write this "123\n456" + "\n" + "789" or "123\n456" + "\n" + "" + "789". --  Adrian Zubarev Sent with Airmail Am 14. April 2017 um 23:54:39, BJ Homer (bjho...@gmail.com) schrieb: On initial intuition, it

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

I disagree, the examples you have provided are more complicated than you might think they are. Before explaining why, I’m going to make things clear about the ‘two modes’ of the multi-line string literal. I’m not sure where this wording has popped out first and I’m not going to search for it.

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

This is all runtime processing. I think the indentation stripping is better done at compile time. You should be able to select the multi-line string constants in your array of stories example and indent them to look good in your code. Then just use the closing delimiter to tell the compiler

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

This would be prefer to follow Scala multiline string which look 1) //Default var code = """header paragraph1""" *Output:* >header >paragraph1 2) var code = """ ...header... ...paragraph1... """.replace("...") *Output:* >header >paragraph1 3) var code = """ |..header...

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

I agree that it is not obvious. At one point I argued that the trailing newline on the last line should be stripped. But for this reason and others I am now in the camp that thinks we should leave the trailing newline alone. If we don't want to include the trailing newline we can always do

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

I’m not saying that the + operator should automatically add a newline. I’m saying that both strings should contain a trailing newline, such that the visible result is the same. By contrast, this would feel really strange: let a = """ This is line one This is line two """ let b = """ This is

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

I disagree. I expect the last result to be from `a + "\n" + b`, for the reasons I outlined earlier. The concatenation operator + does not introduce implied separators when joining strings. There is no reason to think that it should for multi-line strings specifically. On Fri, Apr 14, 2017 at

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

> Consider these two examples: > > let string_1 = """foo""" > > > let string_2 = """ > foo > """ > What’s the intuitive result you’d expect without taking all the long talk > from the list into account? > > Personally, I’d say string_1 == string_2 is true. > I think it’s reasonable

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

Hi Thorsten, I think we’ve found a lightweight alternative solution for that problem. If you add trailing whitespace characters but no backslash the compiler will emit a warning. Depending which line produced the warning, a Fix-it will either add \n\ or a single \ after the last whitespace

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

I agree with Adrian that trailing whitespace which is not followed by a backslash should be stripped, because it is not visible otherwise (unlike in a normal string). -Thorsten > Am 13.04.2017 um 15:32 schrieb Adrian Zubarev via swift-evolution > : > >

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

What do you love about that? > On Apr 14, 2017, at 8:40 AM, Muse M via swift-evolution > wrote: > > 3) > var code = { > """ > Hello World > """ > } ___ swift-evolution mailing list swift-evolution@swift.org

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

In Javascript, this counted as 2 lines which is fine for rendering code, not with HTML5 elements import Foundation print("Hello World!") 1st) In Swift, it's clear to start multi-line on a new line var code = *"""* Hello World *"""* If Swift cannot accept the 1st syntax, below 2nd and 3rd syntax

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

I think I found another argument of not to inject a new line after the last content line, even though it’s not a strong argument. Consider these two examples: let string_1 = """foo""" let string_2 = """ foo """ What’s the intuitive result you’d expect without taking all the long talk

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

On Thu, Apr 13, 2017 at 7:55 PM, Brent Royal-Gordon wrote: > On Apr 13, 2017, at 4:48 PM, Xiaodi Wu wrote: > > You say "this is the example set by `print`", but I don't think anything >> else actually *follows* that example. No other I/O operation in

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

> On Apr 13, 2017, at 4:48 PM, Xiaodi Wu wrote: > > You say "this is the example set by `print`", but I don't think anything else > actually *follows* that example. No other I/O operation in Swift behaves this > way. > > To be more accurate, it's not `print` that

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

On Thu, Apr 13, 2017 at 4:03 AM, Brent Royal-Gordon wrote: > On Apr 12, 2017, at 5:39 PM, Xiaodi Wu wrote: > > On Wed, Apr 12, 2017 at 5:20 PM, Brent Royal-Gordon < > br...@architechies.com> wrote: > >> Wow, maybe I shouldn't have slept. >> >> Okay,

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

Sure thing, everyones opinion is welcome and helps fine tuning the model. Here is a quick illustration of the model I’m pushing. --  Adrian Zubarev Sent with Airmail Am 13. April 2017 um 20:02:44, David Sweeris (daveswee...@mac.com) schrieb: On Apr 13, 2017, at 10:52, Adrian Zubarev

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

> On Apr 13, 2017, at 10:52, Adrian Zubarev > wrote: > > I don’t think it’s a good idea to add optionally character before the closing > delimiter, because it could confuse the reader of the code on how exactly the > actual string lines above will be

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

I don’t think it’s a good idea to add optionally character before the closing delimiter, because it could confuse the reader of the code on how exactly the actual string lines above will be stripped. My personal vision remains as the following example: // 1) """ Line_1 Line_2 """ // result

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

On 13.04.2017 15:41, Brent Royal-Gordon via swift-evolution wrote: On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution > wrote: Take a look at Brent's revised proposal.I personally thin it is perfect. Take a look:

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

> On Apr 13, 2017, at 10:41, Adrian Zubarev > wrote: > > Was the / intended or did you meant to write \? > > Personally I don’t think we’d need that behavior and can fallback to the > natural way using a blank lines or explicit way using the \n character to

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

Was the / intended or did you meant to write \? Personally I don’t think we’d need that behavior and can fallback to the natural way using a blank lines or explicit way using the \n character to solve that issue at the top or bottom of the multi-line string. The model I’m pushing already would

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

On Apr 12, 2017, at 07:52, Thorsten Seitz via swift-evolution wrote: >> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution >> : >> >> Hey folks, >> >> >> We've revised the proposal again. The main difference: You no

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

Btw. shouldn’t we let the core return the current proposal officially for revision, or otherwise it will need to stay ‘long enough’ in it’s revisioned pitch state before we can kick off a second review process! Just saying. --  Adrian Zubarev Sent with Airmail Am 13. April 2017 um 18:21:29,

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

I’ve update my gist to reflect that now: https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9 Simple ‘multi-line string literal’ model Core features: Omitting of (most) backslashes for ". Altering the string with implicit new line injection at the end of the line. Sting

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

That would be good, I think because it would force everyone to be precise in regards to trailing whitespace. And I don't see that as a bad thing. > On Apr 13, 2017, at 9:54 AM, Adrian Zubarev via swift-evolution > wrote: > > I was really confused by your last

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

I was really confused by your last reply. Actually I’ve got a better idea for a fix-it. :-) let str_8 = """↵ foo··↵ """ warning: line # includes trailing space characters in multi-line string literal foo·· ~~ Fix-it: Insert "\n\" (after these

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

The result is not surprisingly to me, at least not if I follow the simplicity of my gist. "Line 1Line2" Notice I put quotes around the string to better showcase the result here in the mailing list. The backslash serves two jobs in lines s0 to s(n - 1): Disable new line injection.

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

Theoretically that would be enough and lightweight solution to that problem, I could live with that. Optimally stripping them automatically would be ideal, however I cannot tell how complicated this might be to implement. A warning that will popup when you included any trailing spaces in a

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

I don't care much for trailing whitespace but I thought we should respect the trailing whitespace in the event that it is significant. If I'm worried about precision in a string, I turn on the display of whitespace characters and make sure everything is as expected. I also think it would

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

Doesn't the principle of least surprise applies here? In most other languages, the final \n is implicit in multi-line strings and heredocs: I think """↵foo↵foo↵" should be equal to "foo\nfoo\n", because this is what most developers will assume. Yes it will not play well with the standard

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

This is not an assumptions but a fact that the trailing spaces cannot and should not exist without an explicit annotation for precision, otherwise the backslash looses one of its main and significant functionality. --  Adrian Zubarev Sent with Airmail Am 13. April 2017 um 15:13:50, Ricardo

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

As already mentioned I revised my opinion about the last content line, because the model I summarized mimics perfectly how you’d write text paragraphs. I’d say most of the time string concatenation is used to combine strings on the same line. A string literal however should only represent the

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

Hi Adrian, My conclusion that we should leave it alone is based on the assumption that someone may consider the trailing whitespace significant and correct. > On Apr 13, 2017, at 9:05 AM, Adrian Zubarev > wrote: > > That would be so wrong, because it’s not

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

That would be so wrong, because it’s not obvious to anyone how long your string will be. """ foo """ I could tell you, that the string from above could have 10k characters, even if you wouldn’t believe me, as it was proposed (and included in yesterday’s toolchain) my claim can be true. The

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

Question: What is the benefit of disabling the indent stripping? I’m not even sure what I should imagine when I read “if the indent stripping is enabled”. My mental model is simple, the compiler looks for line where the closing tripled delimiter is. Takes all space characters in between the

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

I think it's solid and thorough. I think it's winner. > On Apr 13, 2017, at 8:41 AM, Brent Royal-Gordon > wrote: > >> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution >> > wrote: >> >> Take

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

 Thanks again Brent. This version looks great! I think we’re really getting there. > On 13 Apr 2017, at 13:41, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution >>

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

> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution > wrote: > > Take a look at Brent's revised proposal.I personally thin it is perfect. > Take a look: > >

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

Oops, my apologies for misspelling your name. It was a typo. > On Apr 13, 2017, at 8:35 AM, Ricardo Parada via swift-evolution > wrote: > > Adriam > > Take a look at Brent's revised proposal.I personally thin it is perfect. > Take a look: > >

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

Adriam Take a look at Brent's revised proposal.I personally thin it is perfect. Take a look: https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Regarding what you are proposing: Trailing newline We need consensus on whether the trailing

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

> Am 13.04.2017 um 00:20 schrieb Brent Royal-Gordon : > > Wow, maybe I shouldn't have slept. :-) > > Okay, let's deal with trailing newline first. I'm *very* confident that > trailing newlines should be kept by default. This opinion comes from lots of > practical

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

Assuming the multi-line string literal to behave like I summarized it in my last post and that the for loop runs two times, we’d have to alter your example a little, which will then feel natural for concatenation. I use tabs for ident. // Notice the blank line at the end, which does // not

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

Now that I had some sleep I actually revise my opinion about the last line. I took a few hours to sum my thoughts together in a gist, here is a formatted version of it: https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9 Simple ‘multi-line string literal’ model Core

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

> On Apr 12, 2017, at 5:39 PM, Xiaodi Wu wrote: > > On Wed, Apr 12, 2017 at 5:20 PM, Brent Royal-Gordon > wrote: > Wow, maybe I shouldn't have slept. > > Okay, let's deal with trailing newline first. I'm *very*

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

On Apr 12, 2017, at 6:20 PM, Brent Royal-Gordon via swift-evolution > wrote: > Wow, maybe I shouldn't have slept. LOL. My thoughts so far: • If and only if the opening """ is followed by a newline then strip it. • Don't strip the

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

Thanks Brent, I really appreciate the thoughtful response. Apologies for anything I overlooked previously. I agree with most of your points, although I still find myself preferring the common-whitespace logic and leading/trailing newline stripping when considering the pros and cons. It doesn't

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

On Wed, Apr 12, 2017 at 5:20 PM, Brent Royal-Gordon wrote: > Wow, maybe I shouldn't have slept. > > Okay, let's deal with trailing newline first. I'm *very* confident that > trailing newlines should be kept by default. This opinion comes from lots > of practical

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

The example you have provided with where you return a string happens to be short before the multi-line string starts and therefore it looks ‘okay’ at that moment. However this is the exact example which creates the most problems with the multi-line string literal model. If we’re going to allow

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

> On Apr 12, 2017, at 11:58 AM, Jarod Long via swift-evolution > wrote: > > On a separate note, I'd like to bring up the de-indentation behavior I > described earlier again. I still feel that having the position of the closing > delimiter determine how much

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

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

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

Sorry, what do you mean by "pure" or "practical"? On Wed, Apr 12, 2017 at 16:41 John Holdsworth 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

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

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

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

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 < swift-evolution@swift.org> wrote: > I think we’re agreeing. Looks like I need to clarify my last post a > little. When I included the following strings: > >

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

Sorry for spamming the list with small correction mails. The forum cannot come faster so I could edit my typos. Anyways I meant that the example literal won’t work correctly. --  Adrian Zubarev Sent with Airmail Am 12. April 2017 um 23:10:39, Adrian Zubarev (adrian.zuba...@devandartist.com)

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

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.

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

If I understand #2 correctly than it work for this literal. let x = """↵ abc↵ """ Iff we only remove the top new line when the below part is indented than the literal from above would produce "\nabc\n", which I wouldn’t expect. Compared to: let x = """↵ ··abc↵ ··""" In the multi-lined version

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

Below you can read a part of my message to John, where I was testing the toolchain. If that design for the trailing spaces is indented then I disagree with that design choice. In a normal string literal it’s crystal clear that it contains multiple space characters at the end, because it’s

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

Yes, you are right. I tested using the IBM Swift Sandbox . In Xcode the output is as expected with the empty line in between the two lines. > On Apr 12, 2017, at 2:33 PM, Adrian Zubarev > wrote: > > You’re wrong

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

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 (swift-evolution@swift.org) schrieb: this: """ one two """ should be just the same as "one\ntwo\n" If one

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

On 12.04.2017 22:07, John Holdsworth via swift-evolution wrote: Finally.. a new Xcode toolchain is available largely in sync with the proposal as is. (You need to restart Xcode after selecting the toolchain to restart SourceKit)

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

Quickly correcting myself. I meant to say: As already mentioned a couple times the rules can be simplified by disallowing text in the same line after and before the starting/closing delimiters. --  Adrian Zubarev Sent with Airmail Am 12. April 2017 um 21:34:34, Adrian Zubarev

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

Thank you for the toolchain, I’m currently downloading it to test. As already mentioned a couple times the rules can be simplified by disallowing text after and before the starting/leading delimiters. Allow single line tripled string """text""" Multi-lined text should always be between the

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

That’s already a huge part of the proposal. If I understood the indent algorithm correctly than it should already support everyones preferences for their indent style. The indent is determined by the prefix indent before the closing delimiter. The example you proved should, for my

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

Finally.. a new Xcode toolchain is available largely in sync with the proposal as is. (You need to restart Xcode after selecting the toolchain to restart SourceKit) I personally am undecided whether to remove the first line if it

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

This is the most logical newline stripping behavior in my opinion. It's very easy to think about -- all the lines in-between the triple quotes are the contents of the string. Leading and trailing newlines are easily added if desired by adding extra lines. To support that model, I also agree

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

Hey Brent, thanks a lot for working on multi-line strings! You were also talking about """ heredocs. I really liked that idea. Have you abandoned this concept? Given that triple-quotes in Swift are already quite different from the Python version, we could as well go one step further and

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

You’re wrong there, Xcode does print this for me: Line1 Line 2 The new line is there as expected. --  Adrian Zubarev Sent with Airmail Am 12. April 2017 um 20:30:00, Ricardo Parada (rpar...@mac.com) schrieb: print("Line1\n") print("Line 2") ___

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

Okay, so maybe we should not strip the trailing newline. The xml concatenation example in Brent's revised proposal assumes the literal includes a trailing newline. Also, if you do this in Swift: print("Line1\n") print("Line 2") It seems to strip trailing newlines. So the above actually

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

Actually this would be inconsistent. The lines in between the delimiters should always add an implicit new line if not told otherwise with a backslash. If that wouldn’t be the case than you won’t have any precision in the last line you have there. Assume you want to concatenate this string:

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

Hi all, I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline.

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

Agree. I prefer the new rules over the old, but considering common use cases, stripping the leading and trailing newline makes for a more pleasant experience than not stripping either of them. I think that is generally worth prioritizing over a simpler algorithm or even accommodating more styles.

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

On 12.04.2017 17:52, Thorsten Seitz via swift-evolution wrote: Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution : Hey folks, We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation

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

> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution > : > > Hey folks, > > > We've revised the proposal again. The main difference: You no longer need an > initial newline to enable indentation stripping, and stripping no longer > removes that

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

I messed up the indent in the example, where is the corrected version: let myReallyLongXMLConstantName = """ John Doe XML Developer's Guide Computer 44.95 \ """ --  Adrian Zubarev Sent with Airmail Am 12.

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

It was simply a pitch ;) Adding comments it’s not important to me, but I thought it could simply work after the backlash. And multi-line comments /**/ should work fine and are not ambiguous because they also have a clear single line purpose. Remember SE–0102 here public /*closed*/ enum Never {

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

I think I agree that the simplicity of the new rules outweigh the loss of the first newline’s automatic stripping. Good job! > On 12 Apr 2017, at 15:40, Brent Royal-Gordon via swift-evolution > wrote: > > Hey folks, > > > We've revised the proposal again. The main

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

Hi Brent, thank you for the hard work and the new revision. However I still would love to hear your opinion if we should drop the support for these kind of options: """Hello↵ world!""" """↵ Hello↵ world!""" """Hello↵ world! """ I tend to agree that it’s much simpler to only support a single

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

> On Apr 12, 2017, at 5:59 AM, Tony Allevato via swift-evolution > wrote: > > I also would oppose comments inside multi-line strings because one place I > imagine using it is in Swift code generation and I also want to generate > comments, and it seems pointless to

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

> On Apr 12, 2017, at 8:40 AM, Brent Royal-Gordon via swift-evolution > wrote: > > Hey folks, > > > We've revised the proposal again. The main difference: You no longer need an > initial newline to enable indentation stripping, and stripping no longer > removes

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

> Am 12.04.2017 um 14:56 schrieb Xiaodi Wu : > > Sure, but keep in mind you're ultimately presenting a long string to the > user. Chances are if it needs commenting to the reader of the code, it needs > commenting to the reader of the string (which could be code itself,

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

On 12.04.2017 15:59, Tony Allevato via swift-evolution wrote: I also would oppose comments inside multi-line strings because one place I imagine using it is in Swift code generation and I also want to generate comments, and it seems pointless to have to escape those. Let's not over-engineer

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

Hey folks, We've revised the proposal again. The main difference: You no longer need an initial newline to enable indentation stripping, and stripping no longer removes that newline even if it is present. (Adrian Zubarev and I believe some others argued for this.) We disagreed with this at

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

I also would oppose comments inside multi-line strings because one place I imagine using it is in Swift code generation and I also want to generate comments, and it seems pointless to have to escape those. Let's not over-engineer this and end up with feature creep. A simple multi-line string that

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

Sure, but keep in mind you're ultimately presenting a long string to the user. Chances are if it needs commenting to the reader of the code, it needs commenting to the reader of the string (which could be code itself, whether a SQL query or something else). Can you give a use case where

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

Right, I think it might be too much. Consider that the multi-line literal could be code with comments in it, but that you could also escape and embed an actual multi-line comment with \ /* */ that isn't part of the multi-line literal code with multi-line comments! How confusing! On Wed, Apr 12,

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

> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution > : > > I don't think I would use that. I don't find the aesthetics pleasant. > I would rather comment above the string literal. It might be useful when many comments would be required where

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

I don't think I would use that. I don't find the aesthetics pleasant. I would rather comment above the string literal. Would the escape character cause the newline for the line to be ignored thereby continuing the string on the next line? > On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via

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

I agree. That would be very useful. > On Apr 12, 2017, at 6:16 AM, Thorsten Seitz via swift-evolution > wrote: > >> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution >> : >> >> Great explanation thank you Brent. I’m

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

I’d be fine with that. -Thorsten > Am 12.04.2017 um 12:59 schrieb Adrian Zubarev via swift-evolution > : > > One last pitch, can we allow comments in multi-line strings if the string is > broken up by a backslash? > > > let myString = """ > text text >

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

That’s a great revision, Brent! Thanks a lot! I like it as written but would also be totally fine with Xiaodi’s proposition of stripping the trailing newline by default (requiring an empty line for a trailing newline). -Thorsten > Am 11.04.2017 um 15:35 schrieb John Holdsworth

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

One last pitch, can we allow comments in multi-line strings if the string is broken up by a backslash? let myString = """ text text text text text \ // Comment allowed in the current line here, but not in the line above it text text text \ /* this type of comment is fine too */

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

Actually I’m fine with such a compromise. Such a model has everything we’ve asked for, it’s easy, it has both leading and trailing precision and implicit new lines where needed. --  Adrian Zubarev Sent with Airmail Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution

  1   2   >