> 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 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 * Ability to disable escapes except for interpolation (and perhaps to selectively disable other escapes) 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) CONVENIENCES—If we had infinite time...but we don't. And they might be dumb anyway. * Whitespace normalization * Embedded comments * 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
