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.
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)" ?
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.
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
