[swift-evolution] multi-line string literals

[Chris Lattner]

On Dec 10, 2015, at 6:01 PM, Travis Tilley <ttilley at gmail.com> wrote:
> 2) Should escapes like \n be processed always, should they never be processed, or should they be processed by default but disable-able in the syntax?
> 
> 
> I would want multi-line string literals to behave as much like normal string literals as possible for consistency. To optimize for developer happiness, to steal the ruby saying, unexpected behavior should be kept to a minimum. If \n works in a normal string literal, it should work in a multi-line string literal... even if you could just hit enter instead.

Yes, I agree that should be the default.

> 3) What other policy decisions make sense to expose on these literals?  Since this will be the “powerful form of string literals”, it makes sense to be the place to put weird knobs that are seldom used but important in various cases.
> 
> 
> ​I would have to depend entirely on you to inform me of both these knobs and use cases. ​I'd love to hear about them, that's for sure.

The reason I raise the question is that some languages have multiple quote styles (Perl 5 has something like 3 or 4 different string literal styles IIRC?) with different policies.  One reason for this is to disable processing of escapes: if you’re using string literals to enter something that uses \ or “ frequently, it can be irritating and ugly to have a lot of \\'s <smb://'s>.  In some dialects of inline assembly in C, for example, this can lead to very ugly code.

When introducing a feature like this, I think it would be useful to survey a range of popular languages (and yes, even perl ;-) to understand what facilities they provide and why (i.e. what problems they are solving) and synthesize a good swift design that can solve the same problems with a hopefully simple approach.

I haven’t looked into this area deeply myself, so I can’t give you a recipe to just follow, some research is required :)


> My initial goal was the minimal possible work required to decrease the noise of writing large blocks of multi-line text and not have to poke around too much in the lexer and parser code (being completely unfamiliar with the swift codebase, having it just become open source recently).

Understood, but our first goal is to get the best solution, independent of implementation complexity.  In this case, I suspect that the hard part in this feature is scoping it out and hashing out the right design with the community.  I can’t imagine that we’d end up with a design that is that difficult to implement in any case.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/11bc3b9d/attachment.html>