+1 for the proposal as a starting point
> Am 30.04.2016 um 04:37 schrieb Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org>:
>
>> This would ultimately be my favorite approach. I do like the underscores,
>> because they're unobtrusive and don't distract the eye, but I'm interested
>> to see alternative suggestions. However, I understand this is not considered
>> in scope for the current proposal. Is the intention to propose alternate
>> delimiters for Swift 3 now or wait?
>
> My goal is to get Swift 3 string literals to the minimum viable feature set
> for tasks like scripting, templating, using regex libraries, and generating
> code. In my mind, the features I discuss in the "Future directions for string
> literals" section break down like this:
>
> ABSOLUTELY NECESSARY—I definitely intend to propose these for Swift 3.
>
> * Readable multiline strings
> * Ability to disable escapes
yep
>
> REALLY NICE TO HAVE—We'll see how much the community wants them, and how much
> the core team thinks it can handle.
>
> * Alternate delimiters
What’s the use for these if we already can disable escapes (after implementing
the absolutely necessary proposals)?
> * Ability to disable escapes except for interpolation (and perhaps to
> selectively disable other escapes)
That would be really useful (I would tend to push it up into the absolutely
necessary category :-)
>
> REALLY NICE TO HAVE, BUT WE CAN'T—I would love to do these, but they're too
> hard for Swift 3.
>
> * Very long, minimally massaged strings (i.e. heredocs)
Useful, but IMO not very pressing IF the tools support pasting multi line
strings and adding/removing the leading marker
>
> CONVENIENCES—If we had infinite time...but we don't. And they might be dumb
> anyway.
>
> * Whitespace normalization
> * Embedded comments
Embedded comments would be *very* nice. Absolutely sufficient would be the
ability to embed line comments and empty lines, i.e. something like
let foo =
"blabla
"blabla
// some comment here
"blabla
"blabla
// another comment here
"blabla
"blabla
I’m not sure whether more complicated embedded comments (i.e. comments in the
same line as a string line) would be worth the effort but might be doable with
a modifier allowing them, e.g.
c“blabla // some comment
This kind of embedding is certainly out of scope for Swift 3 and possibly Swift
4, but I’m hoping that line comments and empty lines might be even possible in
Swift 3 :-)
-Thorsten
> * Localization
> * Default modifier control
>
> NOT INVENTED YET—Requires huge supporting designs we just don't have.
>
> * Regex literals
> * User-specified modifiers
>
> I think we should definitely propose the items in "Absolutely Necessary" and
> consider proposing the ones in "Really Nice To Have" for Swift 3. I think we
> should definitely do the "Really Nice To Have, But We Can't" item in Swift 4.
> I think we should revisit and consider the others in Swift 4 and beyond.
>
> * * *
>
> I have intentionally described these features very broadly. For instance, I
> said "alternate delimiters", not "the `_` modifier". The specific designs I
> sketched in the proposal are merely examples of solutions to that class of
> problem. Here are a whole slew of other designs just for alternate delimiters:
>
> * Use a different identifier-but-not-capitalizable character, like `$`.
> * Use a different single-character ASCII delimiter, like `'`.
> * Use a different multi-character delimiter, like `"""`.
> * Use a different Unicode delimiter, like smart quotes (`“foo ”`) or French
> quotes (`«foo»`) or Japanese quotes (`⸢foo⸥`).
> * Permit arbitrary delimiters bounded by some specific, known character, like
> (just making this up) `'~~~~~'`.
>
> That's just off the top of my head—there are probably a hundred more of
> these. What is presented in the "Future directions for string literals"
> section is a series of *example* solutions to illustrate the problems that
> need solving, not necessarily the exact thing we must write a proposal for in
> a few months or years. It's a sketch, not a roadmap.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
