> On May 11, 2016, at 12:55 PM, Vladimir.S <sva...@gmail.com> wrote: > > > On 11.05.2016 19:38, Ricardo Parada wrote: >> I did not suggest the single quote because it is commonly found in the >> English language and we would have to escape it. > > Wel.. in your document you have a number of variants of multi-line 'feature' > implementations with different pros/cons for each.
I don’t have a document. I’ve seen different proposals. I have just been commenting on the proposals in this thread. > Could you clarify, why this proposal with single quote can not be inside your > document as just another variant with its own pros/cons ? Especially, as you > can see, if "We'd rather save single quoted literals for a greater purpose > (e.g. non-escaped string literals)” ? I cannot speak for them, but I think that if we want to get a feel about which alternatives get the most traction, I think all alternatives should be considered, including yours and mine. :-) >> >> 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. >> I don’t think we need to worry about the opening quote occurring in the text because we just need the closing delimiter to find out where it ends. For example: let sourceCode = @“NSString *firstName = @“John”; "NSString *lastName = @“Doe”; “NSString *fullName = [NSString stringWithFormat: @“%@ %@“, firstName, lastName];"@ The one that would be a bit of a problem is the closing delimiter, > > And what do you suggest to do if we *have* `"@` inside the text we want to > use ? > >> >> >>> 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