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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >> > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
