This isn’t the most compelling of ideas but a couple of times I’ve found myself writing:
if let value = key != nil ? dict[key] : nil {…
and was wondering if the syntax could be:
if let value = dict[key?] {…
The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety.
Cheers
if let key = key, value = dict[key] {
...whatever...
}
seems to work fine without introducing a new construct
-- E, waving hi to John
On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
This isn’t the most compelling of ideas but a couple of times I’ve found myself writing:
if let value = key != nil ? dict[key] : nil {…
and was wondering if the syntax could be:
if let value = dict[key?] {…
The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety.
Cheers
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
if let value = map(key) { dict($0) }
Félix
Le 22 déc. 2015 à 13:00:45, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :
if let key = key, value = dict[key] {
...whatever...
}seems to work fine without introducing a new construct
-- E, waving hi to John
On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
This isn’t the most compelling of ideas but a couple of times I’ve found myself writing:
if let value = key != nil ? dict[key] : nil {…
and was wondering if the syntax could be:
if let value = dict[key?] {…
The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety.
Cheers
_______________________________________________
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
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.
The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.
There has been some discussion of this before on swift-evolution:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.
This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
I think this would be the standard syntax:
if let value = key.map({ dict[$0] }) {
}
On Dec 22, 2015, at 10:33 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:
if let value = map(key) { dict($0) }
Félix
Le 22 déc. 2015 à 13:00:45, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :
if let key = key, value = dict[key] {
...whatever...
}seems to work fine without introducing a new construct
-- E, waving hi to John
On Dec 22, 2015, at 4:37 AM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
This isn’t the most compelling of ideas but a couple of times I’ve found myself writing:
if let value = key != nil ? dict[key] : nil {…
and was wondering if the syntax could be:
if let value = dict[key?] {…
The key for dictionaries could be made optional in stdlib but this is probably best implemented in the compiler for safety.
Cheers
_______________________________________________
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
-Dave
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: GitHub - Raku/old-design-docs: Raku language design documents.
-Patrick
On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.There has been some discussion of this before on swift-evolution:
[swift-evolution] multi-line string literals
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction
when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string.
Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax
which means you frequently want an un-interpolated string literal. The situation is
far better in Swift with the more distinct \().
Can you think of anything that couldn’t be readily expressed using Python style “””?
John
On 22 Apr 2016, at 19:12, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: https://doc.perl6.org/language/quoting\.
-Patrick
On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.There has been some discussion of this before on swift-evolution:
[swift-evolution] multi-line string literals
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals
Wow, it's pretty cool that this change is so surgical.
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.
I don't think you can tackle multiline strings without worrying about indenting. Indentation may fundamentally change the approach you choose.
I continue to believe that we're actually looking at three orthogonal features here:
* Multiline string literals
* Alternative string literal delimiters
* Disabling escapes in string literals
The way I would prefer to tackle these is:
* Multiline literals: If the closing quote of a string is not present, look at the next line. If it consists of (optional) indentation followed by a matching opening quote, the string has a newline and then continues after the quote on the next line. (The handling of comments is an open question here.)
let xml: String = "<?xml version=\"1.0\"?>
"<catalog>
"\t<book id=\"bk101\" empty=\"\">
"\t\t<author>\(author)</author>
"\t</book>
"</catalog>"
The cool things about this are that (a) the compiler can tell you really do mean this to be part of the literal and you haven't just forgotten to close the string, and (b) there's no guesswork about how indentation should be handled. The uncool thing is that you need to insert the quote at the beginning of each line, so you can't just blindly paste into a multiline literal. Editors can help make that easier, though—a "paste as string literal" feature would be a nice addition to Xcode, and not just for multiline strings or just for Swift.
* Alternative delimiters: If a string literal starts with three, or five, or seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a row are simply literal quote marks. Four, six, etc. quotes is a quote mark abutting the end of the literal.
let xml: String = """<?xml version="1.0"?>
"""<catalog>
"""\t<book id="bk101" empty="">
"""\t\t<author>\(author)</author>
"""\t</book>
"""</catalog>"""
You can't use this syntax to express an empty string, or a string consisting entirely of quote marks, but `""` handles empty strings adequately, and escaping can help with quote marks. (An alternative would be to remove the abutting rule and permit `""""""` to mean "empty string", but abutting quotes seem more useful than long-delimiter empty strings.)
* Disabling escapes: If you use single quotes instead of double quotes, backslash escapes are disabled. (There is no escaping at all, not even \\ or \'. If you need to include the delimiter, use a delimiter with more quote marks. I'm not sure if this should disable interpolation; for now, I'm assuming it should. If it doesn't disable interpolation, the only way to get a \( into the string would be by interpolating it in, not by escaping it somehow.)
let xml: String = '''<?xml version="1.0"?>
'''<catalog>
''' <book id="bk101" empty="">
''' <author>''' + author + '''</author>
''' </book>
'''</catalog>'''
I'm not sure if single quotes should allow interpolation. Options are:
* No, just concatenate (as shown above).
* Yes, with the ordinary syntax: ''' <author>\(author)</author>
* Yes, with a number of backslashes matching the number of quotes, which allows you to insert literal \( text: ''' <author>\\\(author)</author>
Note that you can use these features in any combination. I've shown a few combinations above, but here are some others.
A single-line literal with an alternate delimiter:
""" <book id="bk101" empty="">"""
The same thing, but no-escaping:
''' <book id='bk101' empty=''>'''
A no-escaping multiline literal with a normal delimiter:
'<?xml version="1.0"?>
'<catalog />'
* * *
Notes on alternatives:
1. If you wanted to not provide no-escaping strings, an alternative would be to say that *all* escapes require as many backslashes as there are quotes in the string delimiter. Thus, a newline escape in a `"""` string would be `\\\n`. This would in practice give you the same flexibility to write a literal without worrying (much) about escaping.
2. However, it's not entirely clear to me that we really need escapes other than interpolations at all. You could write "\(.newline)" or "\(.doubleQuote)" or "\(.backslash)" to get those characters. (These might be static members required by StringInterpolationConvertible.) Plain backslashes would have no special meaning at all; only "\(" would be special.
3. It might be useful to make multiline `"` strings trim trailing whitespace and comments like Perl's `/x` regex modifier does. That would allow you to document things in literals. Then you would want `'` again so that you could turn that smartness off. (Of course, the big problem here is that a naïve implementation would consider "http://" to have a comment at the end of it.)
* * *
Finally, a brief aside:
For example, a regular expression that detects a might be written "\N*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n".
There is a special place in Hell reserved for authors of languages which use `\` as an escape character, provide no regex literals or non-escaping string literals, and ship with regex libraries which use `\` as a metacharacter. It's in the outer circles—Satan has some sense of perspective—but it's definitely there.
Sorry if that's not very constructive, but *man*, that burns my biscuits.
--
Brent Royal-Gordon
Architechies
Just ignore me if that's been covered in the archives already (there is a lot there, I'm still catching up), but is there a reason we can't just allow newlines in the existing string constants and be done with it? Since they've been invalid so far, nobody has code that contains line breaks that could be broken. At worst the code formatter would have to be told not to indent such lines, but beyond that, why are newlines in strings not permitted?
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
On 22 Apr 2016, at 18:59, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.
I think this would be the standard syntax:
if let value = key.map({ dict[$0] }) {
}
In this case, I think you actually want a flatMap, to merge the two `nil` cases instead of nesting them.
if let value = key.flatMap({ dict[$0] }) {
}
I wish that could be this, though:
if let value = key.flatMap(dict.subscript) {
}
In any case, I think two different approaches to do this (chained `if let` and `flatMap`) are probably enough; we don't need a third.
--
Brent Royal-Gordon
Architechies
+1
On Fri, Apr 22, 2016 at 11:48 AM, John Holdsworth via swift-evolution < swift-evolution@swift.org> wrote:
As a long time user of Perl, for me the simplicity and lack of flexibility
is the attraction
when it comes to “”” syntax ;) That’s a lot of documentation for just
specifying a string.
--
kurt@CircleW.org
http://www.CircleW.org/kurt/
If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation.
-Patrick
On Apr 22, 2016, at 2:48 PM, John Holdsworth <mac@johnholdsworth.com> wrote:
As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction
when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string.Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax
which means you frequently want an un-interpolated string literal. The situation is
far better in Swift with the more distinct \().Can you think of anything that couldn’t be readily expressed using Python style “””?
John
On 22 Apr 2016, at 19:12, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: GitHub - Raku/old-design-docs: Raku language design documents.
-Patrick
On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.There has been some discussion of this before on swift-evolution:
[swift-evolution] multi-line string literals
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Regex support certainly needs to be kept in mind. I can propose something a little different
on that front however that retains the existing simple literal syntax. Bear with me.
What if invalid escape sequences did not result in an error but were passed through to the string?
This is a very small change to the lexer.
For example:
print( “\w+[\w\d]+” )
\w+[\w\d]+
It’s easy for a developer to know there are only seven valid escapes \0, \r, \n, \”, \’, \\ and \u{NNNN}
so the error is not a particularly helpful one and these escapes do not overlap with regex syntax.
In this way you get the best of both worlds, minimalist string syntax and not have to write “\\w+[\\w\\d]+”
John
On 22 Apr 2016, at 20:54, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation.
-Patrick
On Apr 22, 2016, at 2:48 PM, John Holdsworth <mac@johnholdsworth.com> wrote:
As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction
when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string.Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax
which means you frequently want an un-interpolated string literal. The situation is
far better in Swift with the more distinct \().Can you think of anything that couldn’t be readily expressed using Python style “””?
John
On 22 Apr 2016, at 19:12, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: GitHub - Raku/old-design-docs: Raku language design documents.
-Patrick
On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.There has been some discussion of this before on swift-evolution:
[swift-evolution] multi-line string literals
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Instead of creating yet another set of string quotation rules, I would prefer copy & pasting the Perl 5 rules :)
let x = XMLDocument(<<END_OF_XML)
<xml>
<yes>it works</yes>
</xml>
END_OF_XML
/* I think multiline literals should not consider indentation. If you want to have it formatted nicely, the editor should display a nice text box for you. Editors could do so much more than they are doing now, IMHO. I remember a time when editors refused to interoperate, because one file used a LF line style, while another editor used CRLF. Now, this is no longer a problem, and the reasons are better editors. Editors could also solve the Tabs- versus Spaces-issues or the { bracket styles }, by always keeping the style of the file intact, but displaying the style that the user likes to see. */
let y = q(if you want to use " and ' and even """ in the string itself. You can also use (parenthesis), as long as you balance them properly. A single "q" at the beginning, so no string interpolation here.)
let z = qq/if you want string interpolation, you can have it. BTW x = $(x)/
let w: Array<String> = qw[this is an array of words]
m/regexes are a nice feature too/i
s{if you want to match slashes\(/\), just use another delimiter.}{yes, we can}g
-Michael
Am 23.04.2016 um 23:08 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals
Wow, it's pretty cool that this change is so surgical.
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.I don't think you can tackle multiline strings without worrying about indenting. Indentation may fundamentally change the approach you choose.
I continue to believe that we're actually looking at three orthogonal features here:
* Multiline string literals
* Alternative string literal delimiters
* Disabling escapes in string literalsThe way I would prefer to tackle these is:
* Multiline literals: If the closing quote of a string is not present, look at the next line. If it consists of (optional) indentation followed by a matching opening quote, the string has a newline and then continues after the quote on the next line. (The handling of comments is an open question here.)
let xml: String = "<?xml version=\"1.0\"?>
"<catalog>
"\t<book id=\"bk101\" empty=\"\">
"\t\t<author>\(author)</author>
"\t</book>
"</catalog>"The cool things about this are that (a) the compiler can tell you really do mean this to be part of the literal and you haven't just forgotten to close the string, and (b) there's no guesswork about how indentation should be handled. The uncool thing is that you need to insert the quote at the beginning of each line, so you can't just blindly paste into a multiline literal. Editors can help make that easier, though—a "paste as string literal" feature would be a nice addition to Xcode, and not just for multiline strings or just for Swift.
* Alternative delimiters: If a string literal starts with three, or five, or seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a row are simply literal quote marks. Four, six, etc. quotes is a quote mark abutting the end of the literal.
let xml: String = """<?xml version="1.0"?>
"""<catalog>
"""\t<book id="bk101" empty="">
"""\t\t<author>\(author)</author>
"""\t</book>
"""</catalog>"""You can't use this syntax to express an empty string, or a string consisting entirely of quote marks, but `""` handles empty strings adequately, and escaping can help with quote marks. (An alternative would be to remove the abutting rule and permit `""""""` to mean "empty string", but abutting quotes seem more useful than long-delimiter empty strings.)
* Disabling escapes: If you use single quotes instead of double quotes, backslash escapes are disabled. (There is no escaping at all, not even \\ or \'. If you need to include the delimiter, use a delimiter with more quote marks. I'm not sure if this should disable interpolation; for now, I'm assuming it should. If it doesn't disable interpolation, the only way to get a \( into the string would be by interpolating it in, not by escaping it somehow.)
let xml: String = '''<?xml version="1.0"?>
'''<catalog>
''' <book id="bk101" empty="">
''' <author>''' + author + '''</author>
''' </book>
'''</catalog>'''I'm not sure if single quotes should allow interpolation. Options are:
* No, just concatenate (as shown above).
* Yes, with the ordinary syntax: ''' <author>\(author)</author>
* Yes, with a number of backslashes matching the number of quotes, which allows you to insert literal \( text: ''' <author>\\\(author)</author>Note that you can use these features in any combination. I've shown a few combinations above, but here are some others.
A single-line literal with an alternate delimiter:
""" <book id="bk101" empty="">"""The same thing, but no-escaping:
''' <book id='bk101' empty=''>'''A no-escaping multiline literal with a normal delimiter:
'<?xml version="1.0"?>
'<catalog />'* * *
Notes on alternatives:
1. If you wanted to not provide no-escaping strings, an alternative would be to say that *all* escapes require as many backslashes as there are quotes in the string delimiter. Thus, a newline escape in a `"""` string would be `\\\n`. This would in practice give you the same flexibility to write a literal without worrying (much) about escaping.
2. However, it's not entirely clear to me that we really need escapes other than interpolations at all. You could write "\(.newline)" or "\(.doubleQuote)" or "\(.backslash)" to get those characters. (These might be static members required by StringInterpolationConvertible.) Plain backslashes would have no special meaning at all; only "\(" would be special.
3. It might be useful to make multiline `"` strings trim trailing whitespace and comments like Perl's `/x` regex modifier does. That would allow you to document things in literals. Then you would want `'` again so that you could turn that smartness off. (Of course, the big problem here is that a naïve implementation would consider "http://" to have a comment at the end of it.)
* * *
Finally, a brief aside:
For example, a regular expression that detects a might be written "\N*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n".
There is a special place in Hell reserved for authors of languages which use `\` as an escape character, provide no regex literals or non-escaping string literals, and ship with regex libraries which use `\` as a metacharacter. It's in the outer circles—Satan has some sense of perspective—but it's definitely there.
Sorry if that's not very constructive, but *man*, that burns my biscuits.
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Wouldn’t the natural regex literal syntax be to enclose them in /’s, e.g. /foo*/ ?
I don’t see how this proposal conflicts with that.
-Chris
On Apr 22, 2016, at 12:54 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:
If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation.
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.I don't think you can tackle multiline strings without worrying about indenting. Indentation may fundamentally change the approach you choose.
I agree with this and almost every point you make in your email (and your other subsequent one about one approach maximally general). That said, I wonder if there is a different conclusion that can be reached. I’m going to rearrange your three features a bit:
The way I would prefer to tackle these is:
* Multiline literals: If the closing quote of a string is not present, look at the next line. If it consists of (optional) indentation followed by a matching opening quote, the string has a newline and then continues after the quote on the next line. (The handling of comments is an open question here.)
let xml: String = "<?xml version=\"1.0\"?>
"<catalog>
"\t<book id=\"bk101\" empty=\"\">
"\t\t<author>\(author)</author>
"\t</book>
"</catalog>"The cool things about this are that (a) the compiler can tell you really do mean this to be part of the literal and you haven't just forgotten to close the string, and (b) there's no guesswork about how indentation should be handled. The uncool thing is that you need to insert the quote at the beginning of each line, so you can't just blindly paste into a multiline literal. Editors can help make that easier, though—a "paste as string literal" feature would be a nice addition to Xcode, and not just for multiline strings or just for Swift.
Yes, I completely agree. This is is awesome, and a nice & simple generalization of our existing syntax. It has obvious behavior even if you encounter it in code without knowing about the feature.
* Disabling escapes: If you use single quotes instead of double quotes, backslash escapes are disabled.
We need a way to disable escapes, but it seems to me that (since it is orthogonal to the other concerns) that it should not be tied to the “multiple single quotes” syntax. What is your thought on “modifier” prefix characters for string literals? e.g.:
let x = e”no \escapes \(processed here”
If we supported these, they would be supported with multi-line string literals by putting the modifiers on the first line of the literal, and the multi-line approach above would “just work”. You could introduce several different modifiers, e.g. one that disabled general escapes, but still allowed \(x) for substitution.
* Yes, with a number of backslashes matching the number of quotes, which allows you to insert literal \( text: ''' <author>\\\(author)</author>
Egads!
Notes on alternatives:
1. If you wanted to not provide no-escaping strings, an alternative would be to say that *all* escapes require as many backslashes as there are quotes in the string delimiter. Thus, a newline escape in a `"""` string would be `\\\n`. This would in practice give you the same flexibility to write a literal without worrying (much) about escaping.
I’m really not a fan of requiring “stacking” of escapes to re-enable them. This (IMO) just makes it less likely that you’ll run into an edge case. I also don’t like the “fix" being to have to use 5 quotes around your strings :-)
3. It might be useful to make multiline `"` strings trim trailing whitespace and comments like Perl's `/x` regex modifier does.
If you have modifier characters already, it is easy to build a small zoo full of these useful beasts.
* Alternative delimiters: If a string literal starts with three, or five, or seven, or etc. quotes, that is the delimiter, and fewer quotes than that in a row are simply literal quote marks. Four, six, etc. quotes is a quote mark abutting the end of the literal.
let xml: String = """<?xml version="1.0"?>
"""<catalog>
"""\t<book id="bk101" empty="">
"""\t\t<author>\(author)</author>
"""\t</book>
"""</catalog>"""You can't use this syntax to express an empty string, or a string consisting entirely of quote marks, but `""` handles empty strings adequately, and escaping can help with quote marks. (An alternative would be to remove the abutting rule and permit `""""""` to mean "empty string", but abutting quotes seem more useful than long-delimiter empty strings.)
I agree that there is a need to support alternative delimiters, but subjectively, I find this to be pretty ugly. It is also a really unfortunate degenerate case for “I just want a large blob of XML” because you’d end up using “"” almost all the time, and you have to use it on every line.
For cases like this, I think it would be reasonable to have a “heredoc” like scheme, which does not allow leading indentation, and does work with all the same modifier characters above. I do not have a preference on a particular syntax, and haven’t given it any thought, but this would allow you to do things like:
let str = <<EOF
<?xml version="1.0"?>
<catalog>
\t<book id="bk101" empty="">
\t\t<author>\(author)</author>
\t</book>
</catalog>
EOF
for example. You could then turn off escaping and other knobs using the modifier character (somehow, it would have to be incorporated into the syntax of course).
I generally agree with your down thread remarks about how Swift doesn’t like to have multiple different solutions for the same problem. OTOH, you could look at “” syntax as being analogous to closure exprs, and heredoc syntax as being analogous to nested functions :-)
-Chris
On Apr 23, 2016, at 2:08 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction
when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string.Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax
which means you frequently want an un-interpolated string literal. The situation is
far better in Swift with the more distinct \().Can you think of anything that couldn’t be readily expressed using
Python style “””?
I've long held that the python string quoting styles “just work” and we should
appropriate them rather than reinventing the wheel. In particular, the
ability to write raw strings such as
r'something containing backslashes (\) and quotes (")'
and
r"""something containing backslashes (\), quotes (") and
newlines!"""
economically is extremely useful.
When one needs to embed a fairly large block of text in source, the
ability to use the triple-quoted forms *without* injecting noise on each
line is fantastic.
on Fri Apr 22 2016, John Holdsworth <swift-evolution@swift.org> wrote:
John
On 22 Apr 2016, at 19:12, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: GitHub - Raku/old-design-docs: Raku language design documents.
-Patrick
On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.There has been some discussion of this before on swift-evolution:
[swift-evolution] multi-line string literals
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
_______________________________________________
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
--
Dave
Just ignore me if that's been covered in the archives already (there is a lot there, I'm still catching up), but is there a reason we can't just allow newlines in the existing string constants and be done with it? Since they've been invalid so far, nobody has code that contains line breaks that could be broken. At worst the code formatter would have to be told not to indent such lines, but beyond that, why are newlines in strings not permitted?
In short: Runaway strings. If you forget to include an ending ", the resulting error may be miles away from where you actually made a mistake.
--
Brent Royal-Gordon
Architechies
Doesn't strike me as a problem needing a solution, though. Strings are syntax-colored differently than actual code. So if it's really runaway, you're likely to notice the wrong color. And the likelihood of the code actually still compiling after grabbing the next random quote to terminate its string is rather small, too.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
On 27 Apr 2016, at 03:24, Brent Royal-Gordon <brent@architechies.com> wrote:
Just ignore me if that's been covered in the archives already (there is a lot there, I'm still catching up), but is there a reason we can't just allow newlines in the existing string constants and be done with it? Since they've been invalid so far, nobody has code that contains line breaks that could be broken. At worst the code formatter would have to be told not to indent such lines, but beyond that, why are newlines in strings not permitted?
In short: Runaway strings. If you forget to include an ending ", the resulting error may be miles away from where you actually made a mistake.
This is oversimplifying the problem of escaping. Simply relaxing the grammar for the content of the string literal doesn't always work.
For example, a regular expression that detects a might be written "\N*\n". If escaping is enabled, then the compiler changes "\n" into line feed, which does not have the same meaning to the regular expression engine as "\n".
-Patrick
On Apr 22, 2016, at 11:13 PM, John Holdsworth <mac@johnholdsworth.com> wrote:
Regex support certainly needs to be kept in mind. I can propose something a little different
on that front however that retains the existing simple literal syntax. Bear with me.What if invalid escape sequences did not result in an error but were passed through to the string?
This is a very small change to the lexer.For example:
print( “\w+[\w\d]+” )
\w+[\w\d]+
It’s easy for a developer to know there are only seven valid escapes \0, \r, \n, \”, \’, \\ and \u{NNNN}
so the error is not a particularly helpful one and these escapes do not overlap with regex syntax.In this way you get the best of both worlds, minimalist string syntax and not have to write “\\w+[\\w\\d]+”
John
On 22 Apr 2016, at 20:54, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
If we use a quoting structure similar to Perl6, then we future proof the grammar to accommodate regular expression literals (and multi-line regular expression literals) later. It also gives us the possibility for support for fine-grain control over escaping and interpolation.
-Patrick
On Apr 22, 2016, at 2:48 PM, John Holdsworth <mac@johnholdsworth.com> wrote:
As a long time user of Perl, for me the simplicity and lack of flexibility is the attraction
when it comes to “”” syntax ;) That’s a lot of documentation for just specifying a string.Perl makes life difficult for itself due to it’s rather simplistic $var interpolation syntax
which means you frequently want an un-interpolated string literal. The situation is
far better in Swift with the more distinct \().Can you think of anything that couldn’t be readily expressed using Python style “””?
John
On 22 Apr 2016, at 19:12, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:
This doesn't provide very much flexibility. I'd like to see something more like Perl6's quoting constructs: GitHub - Raku/old-design-docs: Raku language design documents.
-Patrick
On Apr 22, 2016, at 12:59 PM, John Holdsworth via swift-evolution <swift-evolution@swift.org> wrote:
I’ve raised a speculative PR against the Swift Lexer to support multi-line string literals as was
suggested in the very first week Swift was open sourced and before that in various radars.The approach taken is as simple as possible defining multi-line strings as being
delimited by “”” instead of “ and thereafter able to contain new line characters.There has been some discussion of this before on swift-evolution:
[swift-evolution] multi-line string literals
I’m trying to avoid more advanced features such as the handling of indenting which
for me complicates something that if kept simple can be documented very easily.This change will require a evolution proposal so I’d like to take the pulse before I write it up.
Thoughts?
John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution