> My only reservation is what external editors will make of these strings as > there > is no precedent in another programming language I am aware of.
I understand what you mean. The `e` syntax is similar to some things in other languages (C# uses `@`, Python uses `r`, etc.), but so far as I'm aware, we're breaking new ground with the other stuff. On the other hand, we'd hardly be the first language to do exotic things for multiline strings or alternate delimiters. I think people who use general purpose text editors are used to this stuff not always working quite right. > I’ve updated the "reference toolchain" and PR for testing and review. > > http://johnholdsworth.com/swift-LOCAL-2016-05-01-a-osx.tar.gz > https://github.com/apple/swift/pull/2275 Thank you. It is super-cool to be able to take these things out for a test drive. > This implementation still contains the “e” modifier as an example of how they > would be lexed (which I’ll remove before submission as it is outside the > scope > of this proposal) I left a line comment in the pull request about how it's been implemented, but this is great for testing the ergonomics. 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 escape the string literal. I'm currently envisioning `e` as disabling *all* backslash escapes, so these behaviors wouldn't be appropriate. It also looks like interpolation is still enabled in `e` strings. Since other things like `print(e"\w+")` work just fine, I'm guessing this is a bug in the proposal's sketches (not being clear enough about the expected behavior), not your code. I've written a gist with some tests to show how I expect things to work: https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e I haven't looked into Stdlib's testing tools, so I wrote a chunk of code that uses an old Perl testing format I know by heart. If these tests look useful, I'd be happy to help adapt them to the Swift test suite. If you want to look instead of run, the actual tests start around line 100. As I write this, it currently has three failures and two to-do tests (the todos use `e` and `_` at the same time). There are also a couple examples of expected compiler errors at the bottom of the file that you can uncomment. > and one new feature that \ before a newline ignores the newline. This is in the "Future directions for multiline strings" section of the proposal. Having implemented this, how do you feel about it? Does it seem like such a no-brainer that we should just incorporate it into the proposal? > In this implementation modifiers can only be applied to the first segment of > the literal. That is how I imagine this would work. For instance: let swiftCode = e_"print("hello, world!\n") "print("How are you today?")"_ Note that the continuation quote on the second line doesn't say `e` or `_`; it is merely a reminder that we are parsing a string literal, and doesn't need those things. (If we wanted to, of course, we *could* require them. But I don't see much benefit—it would make changing modifiers burdensome.) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
