I did not suggest the single quote because it is commonly found in the English language and we would have to escape it.
That is why I suggested a rare combination using the @" and "@ as the delimiters. Unless your text is Obj-C code it would be rare to find it. > On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution > <swift-evolution@swift.org> wrote: > > Did I miss the proposal for single quote? > > Just found on > https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md > >---------------------< > Single-quotes '' for Character literals: Swift takes the approach of highly > valuing Unicode. However, there are multiple concepts of a character that > could make sense in Unicode, and none is so much more commonly used than the > others that it makes sense to privilege them. We'd rather save single quoted > literals for a greater purpose (e.g. non-escaped string literals). > >---------------------< > > So, what about using of single quote as "special" strings? > > For example, I'd propose to use single quote quotation to say "this string > should be used as-is, no escapes processing" > > 'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo' > > the only 'disallowed' symbol could be the single quote itself, but I propose > the solution used in other languages - duplicate it if we need it in string: > > 'this '' is a single quote in string, and this is another''' > > and also in multiline strings: > > assert( xml == '<?xml version="1.0"?> > '<catalog> > ' <book id="bk101" empty=""> > ' <author>\(author)</author> > // note '' here in string > ' <title>XML Developer''s Guide</title> > ' <genre>Computer</genre> > ' <price>44.95</price> > ' <publish_date>2000-10-01</publish_date> > ' <description>An in-depth look at XML.</description> > ' </book> > '</catalog>') > > (also needs to duplicate single quote if in text. the compromise, yes.) > >> On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: >> I’ve assembled a gist to summarise the main proposals of this thread. >> >> https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf >> >> At the moment there seem to be four proposals for multi-line strings: >> >> 1) Bent’s proposal for continuation quotes where if a conventional string >> does not close, if the first non-whitespace character of the next line is “ >> (or perhaps |) the string is continued. This gives you precise control >> over exactly what is in the string. >> >> 2) Tyler's original proposal involving strings that can contain newlines >> delimited “””like this“”” as they are in python or, _”like this“_. This works >> well in external editors and on github. Indentation is catered for by >> stripping >> any whitespace before the closing quote from all lines in the string. >> >> 3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl >> subject to the same indentation removal rules as “””strings””” above. This >> has the advantage that the literal is clearly separated from your code. >> >> 4) Heck it all, why not all three syntaxes or some combination. >> >> (There is a separate feature that all string literals can be prefixed by >> e as in e”\w\d+” to turn of all escape processing for another day) >> >> While the Swift Lexer could easily accommodate all these syntaxes there was >> talk early on that Swift has more of a "one way, maximally elegant” ethos and >> indeed I find it difficult imagine the Swift Book breathlessly describing >> all three >> formats so I’m wondering if push came to shove which format people would >> chose? >> >> My vote having undergone a "road to damascus" moment now we know it is >> available sooner rather than later is.. HEREDOC! It’s well understood and >> while at first it would seem to not be a good fit for Swift produces clear >> code. >> >> Votes? >> >> John >> >> >> // Multi-line string proposals >> // https://github.com/apple/swift/pull/2275 >> >> // swift-evolution thread: >> // >> http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133 >> >> // These examples should load in the prototype toolchain available >> here: >> // http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz >> >> // The prototype currently parses three new forms of quoting >> // These new types are still string literals for the grammar. >> >> "the existing string literal format" >> _"a format that does not require you to escape " characters"_ // >> possibly redundant >> """a python-style syntax that will accept "'s and newlines in the >> string""" >> <<"HEREDOC" >> A full heredoc implementation (will always end in a newline) >> HEREDOC >> >> // These strings can be modified by prefixing the string by letters >> // There is currently only one, "e" to disable escape processing. >> // This is primarily used when specifying regular expressions. >> >> letstr = "print(\"Hello, world!\\n\")" >> >> assert( e"print(\"Hello, world!\n\")"== str ) >> assert( e_"print("Hello, world!\n")"_ == str ) >> assert( e"""print("Hello, world!\n")""" == str ) >> >> // Continuation quotes allow you to extend a standard string literal >> // over multiple lines. If a string does not close on a line and the >> // first non-whitespace character on the next line is " that line >> // will be a contination of the string including the newline character >> // (unless it is escaped). Interpolation and escapes process as before >> // unless the first segment of the string is modified by the "e" >> prefix. >> >> // The advantage of this format allows you to indent while giving >> // you precise control of exactly what is going into the literal. >> >> letauthor = "Gambardella, Matthew" >> >> letxml = "<?xml version=\"1.0\"?> >> "<catalog> >> " <book id=\"bk101\" empty=\"\"> >> " <author>\(author)</author> >> " <title>XML Developer's Guide</title> >> " <genre>Computer</genre> >> " <price>44.95</price> >> " <publish_date>2000-10-01</publish_date> >> " <description>An in-depth look at creating applications >> with XML.</description> >> " </book> >> "</catalog> >> "" >> print(xml) >> >> // Perhaps, to avoid the zera crossing effect in text editors due to >> // the unbalanced quotes, the continuation character could be "|". >> // (newlines escaped with \ and blank lines are discarded.) >> >> assert( xml == "\ >> |<?xml version=\"1.0\"?> >> |<catalog> >> | <book id=\"bk101\" empty=\"\"> >> | <author>\(author)</author> >> | <title>XML Developer's Guide</title> >> | <genre>Computer</genre> >> | <price>44.95</price> >> | <publish_date>2000-10-01</publish_date> >> | <description>An in-depth look at creating \ >> |applications with XML.</description> >> >> | </book> >> |</catalog> >> |") >> >> >> // _""_ quoted strings also suppport these behaviours but don't >> require >> // escaping of embedded " characters. Think of them as a being >> modifier >> // on conventional string literals. They support continuation quotes. >> >> assert( xml == _"<?xml version="1.0"?> >> "<catalog> >> " <book id="bk101" empty=""> >> " <author>\(author)</author> >> " <title>XML Developer's Guide</title> >> " <genre>Computer</genre> >> " <price>44.95</price> >> " <publish_date>2000-10-01</publish_date> >> " <description>An in-depth look at creating applications >> with XML.</description> >> " </book> >> "</catalog>\n"_ ) >> >> // _"strings"_ could allow newlines and replace """strings""" >> discussed next >> >> assert( xml == _"<?xml version="1.0"?> >> <catalog> >> <book id="bk101" empty=""> >> <author>\(author)</author> >> <title>XML Developer's Guide</title> >> <genre>Computer</genre> >> <price>44.95</price> >> <publish_date>2000-10-01</publish_date> >> <description>An in-depth look at creating applications >> with XML.</description> >> </book> >> </catalog> >> "_ ) >> >> // The triple quoted strings can contain newlines and, unless >> modified by "e" >> // will process interpolations and not require escaping of ". To >> allow indenting, >> // any whitespace characters that preceed the closing """ will be >> removed from >> // each line of the final literal. A warning is shown if lines do >> not contain >> // the exact same indentation characters. Any intial linefeed is >> also removed. >> >> // The advantage of this format is the """ introducer works well >> when syntax >> // highlighting in external editors and github as quotes are always >> balanced. >> >> assert( xml == """ >> <?xml version="1.0"?> >> <catalog> >> <book id="bk101" empty=""> >> <author>\(author)</author> >> <title>XML Developer's Guide</title> >> <genre>Computer</genre> >> <price>44.95</price> >> <publish_date>2000-10-01</publish_date> >> <description>An in-depth look at creating applications >> with XML.</description> >> </book> >> </catalog> >> """ ) >> >> assert( xml != e"""<?xml version="1.0"?> >> <catalog> >> <book id="bk101" empty=""> >> <author>\(author)</author> >> <title>XML Developer's Guide</title> >> <genre>Computer</genre> >> <price>44.95</price> >> <publish_date>2000-10-01</publish_date> >> <description>An in-depth look at creating applications >> with XML.</description> >> </book> >> </catalog> >> """ ) >> >> // heredoc syntax comes in two variants <<"TAG" and <<'TAG' >> (non-escaping, "e" prefix) >> // It applies the same indentation removal rules as does """. This >> change has wider >> // ramifications for the toolchain as compiler tokens are no longer >> in file order >> // and will take a while for a few problems to be ironed out. The >> more consistent >> // <<e"TAG" is a rather clumsy alternative to <<'TAG' for >> non-escaping strings. >> >> // HEREDOC's advantage is that the literal no longer interrupts the >> flow of your code. >> >> assert( (<<"XML" + <<"XML") == xml + xml ) >> <?xml version="1.0"?> >> <catalog> >> <book id="bk101" empty=""> >> <author>\(author)</author> >> <title>XML Developer's Guide</title> >> <genre>Computer</genre> >> <price>44.95</price> >> <publish_date>2000-10-01</publish_date> >> <description>An in-depth look at creating applications with >> XML.</description> >> </book> >> </catalog> >> XML >> <?xml version="1.0"?> >> <catalog> >> <book id="bk101" empty=""> >> <author>\(author)</author> >> <title>XML Developer's Guide</title> >> <genre>Computer</genre> >> <price>44.95</price> >> <publish_date>2000-10-01</publish_date> >> <description>An in-depth look at creating applications with >> XML.</description> >> </book> >> </catalog> >> XML >> >> // For text you do not want to contain newlines, escape them using \ >> >> print( <<"LOREM" ) >> Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do >> eiusmod tempor incididunt \ >> ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis >> nostrud exercitation ullamco \ >> laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure >> dolor in reprehenderit in \ >> voluptate velit esse cillum dolore eu fugiat nulla pariatur. >> Excepteur sint occaecat cupidatat \ >> non proident, sunt in culpa qui officia deserunt mollit anim id est >> laborum.\ >> LOREM >> >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
