> 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.
Okay thanks. I wanted to make sure I wasn’t cluttering the thread with
off-topic conversation. I agree with how you’ve prioritized the items for
proposal.
> 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.
I actually really like the examples of delimiters you sketched out in the
proposal.
I have an idea for `_` as a modifier. What if it indicated that everything
within the string literal is taken as part of the literal? All escapes are
disabled and internal quotes are allowed. The `_` is already used to indicate
in Swift when a value will not be used, so it follows (maybe?) that with
strings it indicates that nothing in the literal will be evaluated. No
expressions are ‘used’, so to speak.
The other suggestion I would make is to only use the `_` modifier at the
beginning, unless I’m missing a reason why the compiler would need it at the
end as well. I just bring it up because that is one less thing to forget to
‘close’ at the end, and it’s cleaner.
Here’s an example:
let string = _”This “string” allows anything
“\(thisWillNotBeEvaluated)
“Neither will these:
“\w+\n
“3 “slashes" are fine too: \\\
“etc. etc.”
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
