Re: [swift-evolution] multi-line string literals.

Hi Tyler, You’re a bit late indeed. The proposal got accepted with some modifications. No single line expression (for now). The last string content line does not add an implicit new line to the resulting string. Text is always in lines (content lines) between the delimiter lines, but never dire

Re: [swift-evolution] multi-line string literals.

I am very much a fan of this type of thing. It's very clear that new line are included in the string. Leading white space is explicit. It is easy to align. It's easy to copy and paste. And there isn't excessive escaping. > On Apr 3, 2017, at 7:00 AM, Ricardo Parada via swift-evolution > wrote

Re: [swift-evolution] multi-line string literals.

This is probably too late, and I still have to read over the rest of the thread, but one possibility would be to just concatenate adjacent string literals (where a one sided string literal extends until the end of the line. E.g. In your example: let string = "Hello " // Three trailing space c

Re: [swift-evolution] multi-line string literals.

> Am 03.04.2017 um 17:09 schrieb Ricardo Parada via swift-evolution > : > > Hi Adrian, > > I'm not sure if I am understanding what you are saying. > > To me a multi-line string literal is not about continuing a "very long > string" into the next line. > > To me a multi-line string literal

Re: [swift-evolution] multi-line string literals.

To me the discussion about precision of multiline strings is missing the point. The biggest use case of this would be when using swift in a more script-like fashion. You just paste something, add a .components(separatedBy: “\n”).map { something() } and you print the result. If you need precision,

Re: [swift-evolution] multi-line string literals.

Why would backslashes at the end of each line be a nice idea? Sent from my iPhone > On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution > wrote: > > I think that there's nothing wrong with two "tools" for the same task in this > case. Multiline strings look better in the code and

Re: [swift-evolution] multi-line string literals.

On Mon, Apr 3, 2017 at 12:53 PM Ben Rimmington wrote: > (Merged 10 days ago) > That's a relief! I thought I was losing my mind that such an obvious optimization had been left on the floor, especially when I also thought I remembered it working before.

Re: [swift-evolution] multi-line string literals.

Hi Pavel, you've misunderstood what I was saying. :) I was focused specifically on the example Adrian posted a few messages up, where he cited wanting something like Python's implicit concatenation when a string is broken across multiple lines but each segment is still quoted; as Ricardo pointed o

Re: [swift-evolution] multi-line string literals.

Thanks! Unfortunately, it didn't make it to Xcode 8.3... > On Apr 3, 2017, at 9:53 PM, Ben Rimmington wrote: > > (Merged 10 days ago) > >> On 3 Apr 2017, at 20:32, Charlie Monroe wrote: >> >>> On Apr 3, 2017, at 9:25 PM, Ben Rimmington wrote: >>> >>>

Re: [swift-evolution] multi-line string literals.

(Merged 10 days ago) > On 3 Apr 2017, at 20:32, Charlie Monroe wrote: > >> On Apr 3, 2017, at 9:25 PM, Ben Rimmington wrote: >> >>> On 3 Apr 2017, at 17:55, Tony Allevato wrote: >>> >>> I just checked with -O and without and was surprised to find that

Re: [swift-evolution] multi-line string literals.

> On Apr 3, 2017, at 9:25 PM, Ben Rimmington via swift-evolution > wrote: > > >> On 3 Apr 2017, at 17:55, Tony Allevato wrote: >> >> I just checked with -O and without and was surprised to find that `let x = >> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal >> "abcdefgh

Re: [swift-evolution] multi-line string literals.

On 03.04.2017 19:58, Peter Dillinger via swift-evolution wrote: Can we try to enumerate the potential hazards and potential useful features associated with multi-line strings? Then perhaps you can judge various proposals based on them. Potential hazards: H1) Forgotten '+' (plus). This affe

Re: [swift-evolution] multi-line string literals.

> On 3 Apr 2017, at 17:55, Tony Allevato wrote: > > I just checked with -O and without and was surprised to find that `let x = > "abc" + "def" + "ghi"` wasn't collapsed into a single string literal > "abcdefghi" in the generated assembly code. Maybe it's more difficult than it > is in some oth

Re: [swift-evolution] multi-line string literals.

I think that there's nothing wrong with two "tools" for the same task in this case. Multiline strings look better in the code and are easier to read and can serve many purposes. By reading different texts from swift dev team I feel like this is something the language was designed with in mind. T

Re: [swift-evolution] multi-line string literals.

> H3) No recovery for tokenization / syntax highlighting. IMHO, this is the > big drawback of Python-style """ strings. A key way this manifests is while typing your program. When you type the opening """, the rest of the text in the file is going to be "inverted" between code and multiline s

Re: [swift-evolution] multi-line string literals.

Can we try to enumerate the potential hazards and potential useful features associated with multi-line strings? Then perhaps you can judge various proposals based on them. Potential hazards: H1) Forgotten '+' (plus). This affects the current idiom where you could end up with part of your in

Re: [swift-evolution] multi-line string literals.

I just checked with -O and without and was surprised to find that `let x = "abc" + "def" + "ghi"` wasn't collapsed into a single string literal "abcdefghi" in the generated assembly code. Maybe it's more difficult than it is in some other languages because of operator overloads and different kinds

Re: [swift-evolution] multi-line string literals.

I would think that the concatenation would get resolved at runtime, unless the compiler gets smart about it. But either way I do not see it as a problem. The reason is that I don't remember ever worrying about the performance of concatenating a few lines of text. :-) Thanks > On Apr 3, 20

Re: [swift-evolution] multi-line string literals.

To me a literal a single entity which is solved at compile time. The concatenation is however resolved at runtime if I’m not mistaken here (it might be optimized at compile time but I still would expect a function executed a couple of times at runtime). Please correct me if I’m wrong here. -

Re: [swift-evolution] multi-line string literals.

How is that better than this? template = "This is the first line.\n" + "This is the second line.\n" + "This is the third line." > On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution > wrote: > > It look prettier without the \n > > It's not laziness. > > I

Re: [swift-evolution] multi-line string literals.

Hi Adrian, I'm not sure if I am understanding what you are saying. To me a multi-line string literal is not about continuing a "very long string" into the next line. To me a multi-line string literal is about having a string literal that represents multiple lines of text, where each line is

Re: [swift-evolution] multi-line string literals.

Ideally what I personally really want is something like in python: template = ("This is the first line.\n" "This is the second line.\n" "This is the third line.") --  Adrian Zubarev Sent with Airmail Am 3. April 2017 um 16:44:24, Adrian Zubarev (adrian.zuba...@devandarti

Re: [swift-evolution] multi-line string literals.

IMHO this is what multi-lined strings are meant for in first place, for better code readability without precision tradeoffs. You’re not expecting multi-lined chained methods to do something else as they’re meant for. We’re allowing multi lines there for readability not for more functionality. T

Re: [swift-evolution] multi-line string literals.

It look prettier without the \n It's not laziness. I want my code to look pretty. > On Apr 3, 2017, at 10:40 AM, Adrian Zubarev > wrote: > > What I was trying to say is that by automatically adding a new line character > does not provide any benefit except of being lazy to type \n. > > //

Re: [swift-evolution] multi-line string literals.

What I was trying to say is that by automatically adding a new line character does not provide any benefit except of being lazy to type \n. // In your model this would be equivalent let s1 = "\n\n\n" let s2 = """ " // However in my model this is an empty string and should be banned "

Re: [swift-evolution] multi-line string literals.

Actually, it would be like this: let veryLongString2 = "word word word" + "word word word" + "word word word" > On Apr 3, 2017, at 10:29 AM, Ricardo Parada via swift-evolution > wrote: > > I think we should focus on taking care of 99% of the cases. If you have a > very long

[swift-evolution] multi-line string literals

To throw another idea into the mix: the string surrounded with double quotes, each line beginning and ending with a single quote. let foo = "This is my ' 'multi line string ' 'with lots of spaces at' 'the end of the above line ' 'and more at the start of ' '

Re: [swift-evolution] multi-line string literals.

I think we should focus on taking care of 99% of the cases. If you have a very long string then you use the good old fashioned string literal concatenation: Let veryLongString2 = "word word word" + "word word word" + "word word word" By the way, the multi-line string should all

Re: [swift-evolution] multi-line string literals.

At quick glance I disagree with (4). If your current string would contain something like "\n\n" would you really use another empty line with a single unescaped quote? If you’re not, you’ll end up adding a single \n, but that on the other than would be strange if you add it at the end of the line

Re: [swift-evolution] multi-line string literals.

To be honest operator concatenation at compile time is confusing and would be really inconsistent to the whole language. func + (lhs: String, ras: String) -> A { … } let a: A = "abc" + "def" This will break that model and disallow that pattern even if it could make some sense in a specific cont

Re: [swift-evolution] multi-line string literals.

What is the purpose of that backslash? It does not feel like an improvement. I think we should focus on: 1. Looking pretty 2. Allow unescaped quote, double quote as well single/double apostrophe characters 3. Allow interpolation 4. No need to add the \n character for each line 5. It should h

Re: [swift-evolution] multi-line string literals.

New line character \n should not become part of the string itself, that would be really confusing and inconsistent to other escaped characters. let mys1 = """my" "multiline" "string""" The idea is in general the same as I showed it, my version might be really overcomplicated, but you’ve got the

Re: [swift-evolution] multi-line string literals.

I still don't really see what's so wrong with just doing: let foo = "This my " + "multiline " + "string" It's only one or two characters more than other proposed styles, and IMO it's not something that should come up all that often; I'm kind of uncomfortable with the idea of

Re: [swift-evolution] multi-line string literals.

I think it quite some overcomplicates the situation. I would prefer: 1. Distinct multiline strings, (e.g. not " but rather """) 2. We could use something like this for precision: let mys1 = """my" "multiline" "string""" // equivalent to "mymultilinestring" let mys2 = """my multiline

Re: [swift-evolution] multi-line string literals.

I don’t really think this is about how to indicate a multi-lined string, where the string starts and ends with something like ", ' or """ is trivial to me. It’s just a decision to make. However the main debate I see with that topic is the ambiguity from the readers perspective. In your example

Re: [swift-evolution] multi-line string literals.

What about """ notation? It could become something like: let mys = """my multiline string""" On Mon, 3 Apr 2017 at 12:35 Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > Simply because it’s always a zero to n space characters at the start of > the line

Re: [swift-evolution] multi-line string literals.

Simply because it’s always a zero to n space characters at the start of the line and at its end. You cannot predict the need of every multi-line string. I don’t disagree that typing out some extra " and \ is tedious, but what I really like about it is, it’s precise. let string = "Hello

Re: [swift-evolution] multi-line string literals.

Yes, but with ", you need to escape " occurrences - which is a fairly common character - I'd say more common than |. The trailing whitespace - why can't it just be included in the string automatically? Just for supporting comments? > On Apr 3, 2017, at 11:19 AM, Adrian Zubarev > wrote: > > T

Re: [swift-evolution] multi-line string literals.

This is almost the same as proposed, but we use " instead of |, however you still don’t have trailing space characters covered like this. --  Adrian Zubarev Sent with Airmail Am 3. April 2017 um 11:16:41, Charlie Monroe (char...@charliemonroe.net) schrieb: You can. I wish I remembered the la

Re: [swift-evolution] multi-line string literals.

You can. I wish I remembered the language this was in (not sure if it's in Scala), but you can do something like: let xml = ''' | | | <...> | ''' This way, if you care about the leading whitespace, you defin

Re: [swift-evolution] multi-line string literals.

My main concern with this approach is that you don’t have any control about indent and you loose pre- and post spacing characters. A concatenating approach is a little tedious but it’s precise. In any situation a multi-lined string is not softly wrapped string, which implies that you will have

Re: [swift-evolution] multi-line string literals.

While I long for multiline string literals, I'd also very like to see a different syntax as in many cases, these can be XML/HTML snippets and the use of quotes is ubiqituous. I'd very much like to see a variant where you can simply paste almost any string without escaping it. For example, Scala

Re: [swift-evolution] multi-line string literals.

Hello Swift community, on Github there is a PR for this proposal, but I couldn’t find any up to date thread, so I’m going to start by replying to the last message I found, without the last content. I really like where this proposal is going, and my personal preference are *continuation quotes*

Re: [swift-evolution] multi-line string literals.

That's my point. You start with a little two-line string and when you see you have those all over your code. A feature is never bad but a feature that may be misused creates temptation to go for bad programming practices, like "I'm using it just this once" and once you're there you never stop. You

Re: [swift-evolution] multi-line string literals.

I don't think the intent of multi-line string literals is to replace files or templating libraries. I use those all the time and are superior. I think it would be handy and make it more pleasant to use for simple cases. Who has not run into a little multi-line literal in your code where you c

Re: [swift-evolution] multi-line string literals.

I'm not in favour of multiline strings. I believe such strings should be stored in plain files and loaded as needed. It makes both the code and the string cleaner to read and maintain. I've had experiences with many languages that offer that resource and I could see what your code can become in ter

Re: [swift-evolution] multi-line string literals.

Something like this might work //string ends on the first line that doesnt start with a " foo( @" " " " \(author) " XML Developer's Guide " Computer " 44.95 " 2000-10-01 " An in-depth look at creating ap

Re: [swift-evolution] multi-line string literals.

On May 11, 2016, at 2:34 PM, Vladimir.S wrote: >> For example: >> >> >> letsourceCode =@“NSString *firstName = @“John”; >> "NSString *lastName = @“Doe”; >> “NSString *fullName = [NSString stringWithFormat: @“%@ >> %@“, firstName, lastName];"@ >> >> The one t

Re: [swift-evolution] multi-line string literals.

Inline On 11.05.2016 21:04, Ricardo Parada wrote: On May 11, 2016, at 12:55 PM, Vladimir.S mailto:sva...@gmail.com>> wrote: On 11.05.2016 19:38, Ricardo Parada wrote: I did not suggest the single quote because it is commonly found in the English language and we would have to escape it. We

Re: [swift-evolution] multi-line string literals.

> On May 11, 2016, at 12:55 PM, Vladimir.S wrote: > > > On 11.05.2016 19:38, Ricardo Parada wrote: >> I did not suggest the single quote because it is commonly found in the >> English language and we would have to escape it. > > Wel.. in your document you have a number of variants of multi-lin

Re: [swift-evolution] multi-line string literals.

On 11.05.2016 19:38, Ricardo Parada wrote: I did not suggest the single quote because it is commonly found in the English language and we would have to escape it. Wel.. in your document you have a number of variants of multi-line 'feature' implementations with different pros/cons for each.

Re: [swift-evolution] multi-line string literals.

I did not suggest the single quote because it is commonly found in the English language and we would have to escape it. That is why I suggested a rare combination using the @" and "@ as the delimiters. Unless your text is Obj-C code it would be rare to find it. > On May 11, 2016, at 10:50 A

Re: [swift-evolution] multi-line string literals.

Did I miss the proposal for single quote? Just found on https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md >-< Single-quotes '' for Character literals: Swift takes the approach of highly valuing Unicode. However, there are multiple concepts of a chara

Re: [swift-evolution] multi-line string literals.

These are my comments so far. Regarding the use of _” and “_ : It works but I think the _ already has a meaning elsewhere and may bring just a little bit of confusion at first. But more than that, I’m not sure I like the way it looks aesthetically. I can’t quite explain it. It is one charact

Re: [swift-evolution] multi-line string literals.

+1 for the proposal as a starting point > Am 30.04.2016 um 04:37 schrieb Brent Royal-Gordon via swift-evolution > : > >> This would ultimately be my favorite approach. I do like the underscores, >> because they're unobtrusive and don't distract the eye, but I'm interested >> to see alternativ

Re: [swift-evolution] multi-line string literals.

I’ve assembled a gist to summarise the main proposals of this thread. https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf At the moment there seem to be four proposals for multi-line strings: 1) Bent’s proposal for continuation quotes where if a conventional string does not close

Re: [swift-evolution] multi-line string literals.

Btw, in c# we have @ to drop escapes: @"c:\Docs\Source\a.txt" // rather than "c:\\Docs\\Source\\a.txt" @"""Ahoy!"" cried the captain." // "Ahoy!" cried the captain. and(!) also as 'marker' that allows to use keywords as identifiers: class @class { public static void @static(bool @bool) {..} .

Re: [swift-evolution] multi-line string literals.

> By the way has the backtick or triple backtick been considered? Backticks already have a meaning—they "quote" an identifier which would otherwise be taken as a keyword. -- Brent Royal-Gordon Sent from my iPhone > On May 8, 2016, at 2:58 PM, Ricardo Parada wrote: > > The _" and "_ are a g

Re: [swift-evolution] multi-line string literals.

The _" and "_ are a good alternative I think. For some reason the underscore bothers me: it doesn't look as good aesthetically as others, and because it is already used for a couple of other things in Swift (to make large numbers readable and as a placeholder to discard a value). By the way

Re: [swift-evolution] multi-line string literals.

Regards (From mobile) > On May 8, 2016, at 12:49 AM, Ricardo Parada via swift-evolution > wrote: > > > > It seems to me like this would take care of what is needed 99% of the time. > > I've seen many who don't favor continuation quotes. > > The other option could be triple quote """ and

Re: [swift-evolution] multi-line string literals.

It seems to me like this would take care of what is needed 99% of the time. I've seen many who don't favor continuation quotes. The other option could be triple quote """ and make the continuation quote optional. Not using the continuation quote would require the closing triple quote """ >

Re: [swift-evolution] multi-line string literals.

I have a simple working prototype where the following just works Let v = _" "key": "value" "_ I am working on adding Let v = /* this is a template */ _" "key": "value" "_ Let v @string_literal(json) = /* this is a template */ _" "key": "value" "_ This strikes me as far less intru

Re: [swift-evolution] multi-line string literals.

Would you all be so kind to take a look at what I suggestedand wrote appr. a week ago? (data lines) This is with using:    \@   for verbatim as-is character data  and    \\ for character data with processing of \ escaped chars and \(var)The advantage of what I describe is that apart from th

Re: [swift-evolution] multi-line string literals.

hello, Have read all? conversations about this subject... Would you all be so kind to take a look at what I suggested and wrote appr. a week ago? (data lines) This is with using: \@ for verbatim as-is character data and \\ for character data with processing of \ escaped chars

Re: [swift-evolution] multi-line string literals.

> On 6 May 2016, at 20:09, Tyler Cloutier wrote: > >> >> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon > > wrote: >> >>> As far as mixed whitespace, I think the only sane thing to do would be to >>> only allow leading tabs *or* spaces. Mixing tabs and spaces

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon > wrote: > >> As far as mixed whitespace, I think the only sane thing to do would be to >> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >> whitespace would be a syntax error. All lines in the string would need t

Re: [swift-evolution] multi-line string literals.

> On May 6, 2016, at 7:13 PM, L Mihalkovic wrote: > > As I (believe I) start to understand the parser, I somehow think that doing > something like the following would > not violate (not take too much risk) the current Lexer/Parser > be somewhat reasonable to implement > address many of the req

Re: [swift-evolution] multi-line string literals.

As I (believe I) start to understand the parser, I somehow think that doing something like the following would not violate (not take too much risk) the current Lexer/Parser be somewhat reasonable to implement address many of the reqs I read leave some infrastructure in the Lexer/Parser to add mo

Re: [swift-evolution] multi-line string literals.

Sent from my iPad On May 6, 2016, at 12:52 AM, Brent Royal-Gordon wrote: >> As far as mixed whitespace, I think the only sane thing to do would be to >> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >> whitespace would be a syntax error. All lines in the string

Re: [swift-evolution] multi-line string literals.

Sent from my iPad > On May 6, 2016, at 12:14 AM, L. Mihalkovic > wrote: > > Inline > > Regards > (From mobile) > >> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution >> wrote: >> >> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution wrote: >>>

Re: [swift-evolution] multi-line string literals.

> Am 06.05.2016 um 05:24 schrieb Ricardo Parada : > > I think that is another one of the advantages of using the continuation > quotes. > > Sent from my iPhone > >> On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I think it's nice that I can look at any l

Re: [swift-evolution] multi-line string literals.

> assert( xml != ei""" > > >\(author) >XML Developer's Guide >Computer >44.95 >2000-10-01 >An in-depth look at creating applications > with

Re: [swift-evolution] multi-line string literals.

> As far as mixed whitespace, I think the only sane thing to do would be to > only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading > whitespace would be a syntax error. All lines in the string would need to > use tabs or all lines use spaces, you could not have one line w

Re: [swift-evolution] multi-line string literals.

Inline Regards (From mobile) > On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution > wrote: > > >>> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution >>> wrote: >>> >>> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution wrote:

Re: [swift-evolution] multi-line string literals.

If we use triple quotes (i.e. """) at the beginning of the multi line string literal and again at the end, it seems very unlikely that the heredoc notation would be needed. I would simplify and remove the heredoc alternative from the proposal. Also, for those of us who like the continuation q

Re: [swift-evolution] multi-line string literals.

I think that is another one of the advantages of using the continuation quotes. Sent from my iPhone > On May 5, 2016, at 4:51 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I think it's nice that I can look at any line—out of context, random > access—and see which parts are string

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution > wrote: > > >> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 5 May 2016, at 14:17, David Hart >> > wrote: >>> >>> On

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 6:27 PM, Tyler Cloutier via swift-evolution > wrote: > > >> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 5 May 2016, at 14:17, David Hart >> > wrote: >>> >>> On

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution > wrote: > > >> On 5 May 2016, at 14:17, David Hart > > wrote: >> >> >>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> it's no

Re: [swift-evolution] multi-line string literals.

> On 5 May 2016, at 14:17, David Hart wrote: > > >> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> it's not a secret that I'm not a big fan of the proposal. The third draft >> doesn't change this and it's unlikely that any f

Re: [swift-evolution] multi-line string literals.

I admit I have not been following this closely and have not read all proposals and counter proposals and concerns - but of course that isn’t going to stop me from tossing out my own suggestion! My idea starts with this: let code = #string // some code that we are generating + #string a

Re: [swift-evolution] multi-line string literals.

> It had the idea that maybe the motivation behind continuation quotes is to > make using multiline strings harder to use; in order to discourage their use > at all. Absolutely not, and frankly I resent the implication. I'm looking at a space where (in my opinion) all existing designs are ugly

Re: [swift-evolution] multi-line string literals.

I like the continuation quote. It makes the code stay pretty. It doesn't break the indentation of your code. If you take out the continuation quote then things look out of place, as if someone pasted text in the middle of your code by mistake. I don't like the heredoc notation either for the sam

Re: [swift-evolution] multi-line string literals.

I like the continuation quote. It makes the code stay pretty. It doesn't break the indentation of your code. If you take out the continuation quote then things look out of place, as if someone pasted text in the middle of your code by mistake. I don't like the heredoc notation either for the sam

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 12:30 PM, Michael Peternell via swift-evolution > wrote: > > Hi, > > it's not a secret that I'm not a big fan of the proposal. The third draft > doesn't change this and it's unlikely that any future draft will, because for > me, the problem are the continuation quotes, a

Re: [swift-evolution] multi-line string literals.

It was not obvious reading this proposal whether comment lines or empty lines could be inserted in the middle of the multi-line string (MLS). For instance, would the following be syntactically legal or not: let cat = " /* Add as many book specs here as you want */ "

Re: [swift-evolution] multi-line string literals.

> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution > wrote: > > it's not a secret that I'm not a big fan of the proposal. The third draft > doesn't change this and it's unlikely that any future draft will, because for > me, the problem are the continuation quotes, and for Brent

Re: [swift-evolution] multi-line string literals.

Hi, it's not a secret that I'm not a big fan of the proposal. The third draft doesn't change this and it's unlikely that any future draft will, because for me, the problem are the continuation quotes, and for Brent it seems like they are a must-have-feature (correct me if I'm wrong.) I just wa

Re: [swift-evolution] multi-line string literals.

Rust and Scala support macros, C++ has templates, and even the venerable C has #defines. Introducing mera-programming is by no means easy as it generally equates introducing a second, more limited, language inside the original. There exists today an opportunity to take advantage of the string li

Re: [swift-evolution] multi-line string literals.

Comments inline. > On May 4, 2016, at 7:57 PM, Brent Royal-Gordon wrote: > They separate indentation from the string's contents. Traditional multiline > strings usually include all of the content between the start and end > delimiters, including leading whitespace. This means that it's usually

Re: [swift-evolution] multi-line string literals.

> On 4 May 2016, at 15:07, L. Mihalkovic wrote: > > Cool job!.. Yup, you proceed by "widening the existing holes" to carry the > missing info (eg Modifiers). Making direct changes to lexCharacter() is a > step I thought might be a bit premature considering nothing is carved in > stone yet. I

Re: [swift-evolution] multi-line string literals.

> On May 4, 2016, at 1:51 PM, John Holdsworth wrote: > > … response inline > >>> On May 2, 2016, at 2:23 PM, John Holdsworth wrote: >>> >>> I'm having trouble getting the `e` modifier to work as advertised, at least for the sequence `\\`. For example, `print(e"")` prints two

Re: [swift-evolution] multi-line string literals.

… response inline > On May 2, 2016, at 2:23 PM, John Holdsworth > wrote: > >> >>> I'm having trouble getting the `e` modifier to work as advertised, at least >>> for the sequence `\\`. For example, `print(e"")` prints two >>> backslashes, and `print(e"\\\")

Re: [swift-evolution] multi-line string literals.

inline Regards (From mobile) On May 2, 2016, at 2:23 PM, John Holdsworth mailto:m...@johnholdsworth.com>> wrote: > >> I'm having trouble getting the `e` modifier to work as advertised, at least >> for the sequence `\\`. For example, `print(e"")` prints two backslashes, >> and `print(e"\\\

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, David Waite wrote: > In my opinion, one problem is that we don’t have a reference to a > laundry or wish list of what features we would like around string > literals in the language. Without evaluating a proposal against all of > those features (moves forward, doesn’t impact,

Re: [swift-evolution] multi-line string literals.

on Sat Apr 30 2016, Brent Royal-Gordon wrote: >> Second, this proposal should explain why it's reinventing the wheel >> instead of standardizing existing, very successful, prior art. > Answer >> the question: “what compelling advantages does this syntax have over >> Python's?” > > Sure. > > Firs

Re: [swift-evolution] multi-line string literals.

Hi swift-evo, Forgive my naive interjection here. I’ve enjoyed lurking on this list and watching all the discussions around topics I don’t even fully understand, but this one strikes me. I certainly agree that multi-line literals should be undistorted, and I also agree that they should be 100

Re: [swift-evolution] multi-line string literals.

On 5/2/16 09:53, Brent Royal-Gordon via swift-evolution wrote: > When you are embedding enormous string literals in source code, you > must put undistorted representation of the string above all other > considerations. If the design which best permits the string to be > w

Re: [swift-evolution] multi-line string literals.

Inline Regards LM (From mobile) > On May 2, 2016, at 2:23 PM, John Holdsworth wrote: > > >> I'm having trouble getting the `e` modifier to work as advertised, at least >> for the sequence `\\`. For example, `print(e"")` prints two backslashes, >> and `print(e"\\\")` seems to try to escap

Re: [swift-evolution] multi-line string literals.

> So I’m pretty late to the discussion here, but my question is; do we really > want to encourage large blocks of text in code? It's not written up, but it has occurred to me that, rather than having `"""` strings or even heredocs for large chunks of text, we might want something which puts the

  1   2   >