Thread wrap up
Tomorrow is the end of the review period so I’d like to try to summarise what I have taken from the thread.
I’ve published an updated version of the proposal for discussion here.
Summarising the story so far, this proposal puts forward a syntax for raw string literals which are strings where
\ is passed through to the literal and has no special escaping powers. The suggested syntax is now
#raw(“a string with a \”) rather than
r”a string with a \” as in the original proposal merged into swift-evolution master at the beginning of this process.
This version of the proposal includes “customs delimiters lite” as originally put forward by @hooman at the beginning of the thread and later echoed by @Erica_Sadun.
Removing the “closing would be reversed” so your favourite emoji works, this would be a valid raw string:
In addition, the new version of the proposal includes what you could call “interpolating raw strings” which ignore escapes except for the sequence
\(…) which can be used to interpolate. I propose the following syntax with double bracketing of the literal to turn this variant on:
Revisiting the code which prompted me to start this process I realised it doesn’t take long before you find yourself needing this feature and the sequence
\( is sufficiently rare outside Swift that this shouldn’t be a problem.
You can combine raw literals, custom delimiter syntax and interpolation with multi-line string literals
Multiline raw literals would follow the same indentation removal rules as before.
That about covers it unless there is something I’ve missed. There is a Xcode toolchain with an implementation available here
I’m now firmly of the opinion that
#raw(“a literal”) is about is good as we’re going to get. With any raw literal there is absolutely no way to escape the delimiter, so all single character delimiters (whichever quote you use) are simply not useful in the general case. This excludes
'a string' from contention. You get many more options if you move to
#raw(“a string”) which has, at a minimum, a closing delimiter of
“) and you can now extend that using custom delimiter sequences.
To give the core team something to go on, Id like to call a straw poll on this new version of the proposal. Please respond what you would like the outcome to be:
+1: Accepted with revisions - New version of the proposal looks good.
-1: Reject - I don’t see the need for the feature
Apologies for the slightly chaotic progression of the review but I really feel we have explored the space quite thoroughly now and been able to put in front of the Core Team enough information for them to make a decision.