[swift-evolution] multi-line string literals.

Thorsten Seitz tseitz42 at icloud.com
Tue May 10 12:31:29 CDT 2016


+1 for the proposal as a starting point


> Am 30.04.2016 um 04:37 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list