[swift-evolution] multi-line string literals
ttilley at gmail.com
Thu Dec 10 23:37:54 CST 2015
On Fri, Dec 11, 2015 at 12:02 AM, Chris Lattner <clattner at apple.com> wrote:
> 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. In some dialects of inline assembly in C, for example, this can
> lead to very ugly code.
Since the suggestion is python style multi-line string literals, the only
valid terminator would be a triple quote, allowing the use of both " and '
within the literal without having to be escaped (or "" or '', if you're
feeling perverse). As for anything else... I hadn't really thought of it.
I'd really need more feedback on the mailing list.
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.
Perl and Erlang are unique in that valid code in either language looks
essentially like line noise. I'd rather take inspiration from languages
like ruby, python, and elixir.
Solving a variety of problems and use cases was not my original intention,
and will probably involve implementing full heredoc style syntax (or more).
If that's where you want the proposal to go, then that's where it will have
to go... but for myself, I don't need anything nearly that complex. I only
need multi-line string literals that behave the same as existing string
literals, only without the noise of "foo\n" + "bar\n" + "baz\n" + etc.
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.
Fair enough. Lets give the idea some time to ferment and community members
time to chime in. ;)
As an aside, I am absolutely loving that Apple is making such an effort to
care about its community. This is something that I wouldn't have expected
just a few years ago and is amazing in my humblest of opinions. <3
- Travis Tilley
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution