[swift-evolution] multi-line string literals.

[Patrick Gili]

This is oversimplifying the problem of escaping. Simply relaxing the grammar for the content of the string literal doesn't always work.

For example, a regular expression that detects a might be written "\N*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n".

-Patrick

> On Apr 22, 2016, at 11:13 PM, John Holdsworth <mac at johnholdsworth.com> wrote:
> 
> Regex support certainly needs to be kept in mind. I can propose something a little different
> on that front however that retains the existing simple literal syntax. Bear with me.
> 
> What if invalid escape sequences did not result in an error but were passed through to the string?
> This is a very small change to the lexer.
> 
> For example:
> 
>> print( “\w+[\w\d]+” )
> \w+[\w\d]+
> 
> It’s easy for a developer to know there are only seven valid escapes \0, \r, \n, \”, \’, \\  and \u{NNNN}
> so the error is not a particularly helpful one and these escapes do not overlap with regex syntax.
> 
> In this way you get the best of both worlds, minimalist string syntax and not have to write “\\w+[\\w\\d]+”
> 
> John
> 
>> On 22 Apr 2016, at 20:54, Patrick Gili <gili.patrick.r at gili-labs.com> wrote:
>> 
>> If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation.
>> 
>> -Patrick
>> 
>>> On Apr 22, 2016, at 2:48 PM, John Holdsworth <mac at johnholdsworth.com> wrote:
>>> 
>>> As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction
>>> when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string.
>>> 
>>> Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax
>>> which means you frequently want an un-interpolated string literal. The situation is
>>> far better in Swift with the more distinct \().
>>> 
>>> Can you think of anything that couldn’t be readily expressed using Python style “””?
>>> 
>>> John
>>>> On 22 Apr 2016, at 19:12, Patrick Gili <gili.patrick.r at gili-labs.com> wrote:
>>>> 
>>>> This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: https://doc.perl6.org/language/quoting.
>>>> 
>>>> -Patrick
>>>> 
>>>>> On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
>>>>> suggested in the very first week Swift was open sourced and before that in various radars.
>>>>> 
>>>>> https://github.com/apple/swift/pull/2275
>>>>> 
>>>>> The approach taken is as simple as possible defining multi-line strings as being
>>>>> delimited by “”” instead of “ and thereafter able to contain new line characters.
>>>>> 
>>>>> There has been some discussion of this before on swift-evolution:
>>>>> 
>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html
>>>>> 
>>>>> I’m trying to avoid more advanced features such as the handling of indenting which
>>>>> for me complicates something that if kept simple can be documented very easily.
>>>>> 
>>>>> This change will require a evolution proposal so I’d like to take the pulse before I write it up.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> John
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>> 
>> 
>