In my opinion, one problem is that we don’t have a reference to a laundry or
wish list of what features we would like around string literals in the
language. Without evaluating a proposal against all of those features (moves
forward, doesn’t impact, creates later issues for) it is hard to evaluate.
My guess here at an exhaustive list:
Main goals:
- reduce the impact on readability when dealing with certain kinds of string
literals
- reduce the amount of editing needed when inserting/referencing text from an
external source to be used as a string literal
Specific tasks/asks:
- for large string literals, reduce the amount of editing needed to span
multiple lines
- for strings literals meant to represent multi-line text, allow the visual
newline to be used rather than an encoding
(note: this may mean in the first case newlines are considered
formatting of the literal, while in the second they are considered part of the
represented text)
- with string literals spanning multiple lines, allow for the author to indent
the literal to match flow with surrounding code without impacting the
represented text
- allow for text with double quotes to be represented in a string literal
without requiring those quotes to be escaped
- have the ability to disable all/most escape interpretation to reduce impact
on readability of certain text
- take into account that regular expressions, when added, will likely require
different escaping rules than text string literals
Approach-specific
- if allowing for inline blocks of strings delimited by start/end points e.g.
here docs, data segments
- if the block end is on its own line, control whether that newline is
part of the represented text
-DW
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
