<div dir="ltr">This proposed addition addresses a known pain point, to be sure, but I think it has many implications for the future direction of the language and I'd like to explore them here.<div><br></div><div>The tl;dr version is that I'm not sure this is the right direction in which to head to address the issue of regex ergonomics, and that the issue also implicates other weaknesses in terms of literals for which I think the solution exacerbates rather than solves the underlying problem. [Chris's email just came through and cut to the meat of it, but I'll keep writing this email and complete my thoughts.]<div><br></div><div>We've been talking on this list for quite some time about supporting `/this syntax/` for a regex literal. Whether this can be accomplished or not within the Swift 5 timeframe (and I think a reasonable barebones implementation could be), the question here is whether your proposed addition serves any useful purpose in a future version of Swift in which we do have such a literal. After all, your motivation (and a very valid one) is that regex literals are too difficult to type. I very strongly believe that the solution here is what we've been talking about all along: actual regex literals.</div><div><br></div><div>We should certainly move any discussion about regex literals into its own thread, but to make it clear that I'm not simply suggesting that we implement something in Swift 10 instead of addressing a known pain point now, here's a sketch of how Swift 5 could make meaningful progress:</div><div><br></div><div>- Teach the lexer about basic /pattern/flag syntax.</div><div>- Add an `ExpressibleByRegularExpressionLiteral`, where the initializer would be something like `init(regularExpressionLiteralPattern: String, flags: RegularExpressionFlags)` where RegularExpressionFlags would be an OptionSet type.</div><div>- Add conformance to `ExpressibleByRegularExpressionLiteral` to `NSRegularExpression`.</div><div>- Have no default `RegularExpressionLiteralType` for now so that, in the future, we can discuss and design a Swift standard library regular expression type, which is justifiable because we've baked in language support for the literal. This can be postponed.</div><div><br></div><div>Now, suppose we can motivate "raw" strings with some other use case. The proposed syntax remains problematic and I'd like to discuss that for a little bit.</div><div><br></div><div>I believe it was Chris who originally explained some time ago that it was a deliberate design decision not to have little dangling bits on literals such as "1.0f", opting instead for more readable spellings such as "1.0 as Float". This `r` prefix is clearly undoing that deliberate design decision and inconsistent with the direction of Swift. There are other options here, should a use case arise that successfully motivate "raw" strings. For example, one might be to use the long-reserved single-quoted 'string literal' for this purpose, if this is judged to be a significant enough feature that can justify it.</div><div><br></div><div>But there's another matter here that I'd like to touch on. Namely, for all literal types, the `ExpressiblyBy*` protocols expose a processed version of the literal. This leads to various issues that require hacky workarounds at best. For instance, BigInt types can't initialize arbitrarily large values with integer literals, because the literal has to be representable as a built-in fixed-width integer; Decimal initializes its floating-point literal values through a Double intermediary, which can lead to undesirable results; and so on. What these issues have in common with your use case here is the inability of `ExpressibleBy*` types to receive the underlying "raw" literal as it is input. If we could come up with a holistic solution here, we might be able to dispense with having any distinct syntax for "raw" strings *and* solve all of these issues at once.</div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 23, 2017 at 11:43 AM, John Holdsworth via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>Hello S/E,</div><div><br></div><div>I’d like to put forward a perhaps rather banal change to the Swift lexer</div><div>primarily intended to make entering regular expression patterns easier.</div><div><br></div><div><a href="https://github.com/DoubleSpeak/swift-evolution/blob/master/proposals/NNNN-raw-string-escaping.md" target="_blank">https://github.com/<wbr>DoubleSpeak/swift-evolution/<wbr>blob/master/proposals/NNNN-<wbr>raw-string-escaping.md</a></div><div><br></div><div><div>With a raw literal a string prefixed by “r” the \ character would have no</div><div>special role at all and be processed like any other character i.e.</div><div><br></div></div><div><div style="margin:0px;line-height:normal;background-color:rgb(255,255,255)"><div style="margin:0px;line-height:normal"><div style="margin:0px;line-height:normal"><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(209,47,27)"><div style="margin:0px;line-height:normal"><span style="color:rgb(0,0,0)"> r</span>"\n\(var)\n"<span style="color:rgb(0,0,0)"> </span><span style="text-decoration:underline;color:rgb(0,0,0)">=</span><span style="color:rgb(0,0,0)">= </span>"\\n\\(var)\\n"</div><div style="margin:0px;font-size:12px;line-height:normal;font-family:Helvetica;min-height:14px"><br></div><div style="margin:0px;line-height:normal"><span style="color:rgb(0,0,0)"> r</span>"\?\y\="<span style="color:rgb(0,0,0)"> </span><span style="text-decoration:underline;color:rgb(0,0,0)">=</span><span style="color:rgb(0,0,0)">= </span>"\\?\\y\\="</div><div style="margin:0px;font-size:12px;line-height:normal;font-family:Helvetica;min-height:14px"><br></div><div style="margin:0px;line-height:normal"><span style="color:rgb(0,0,0)"> r</span>"c:\windows\system32"<span style="color:rgb(0,0,0)"> </span><span style="text-decoration:underline;color:rgb(0,0,0)">=</span><span style="color:rgb(0,0,0)">= </span>"c:\\windows\\system32"</div><div style="margin:0px;font-size:12px;line-height:normal;font-family:Helvetica;min-height:14px"><br></div><div style="margin:0px;line-height:normal;color:rgb(0,0,0)"> r<span style="color:rgb(209,47,27)">"""</span></div><div style="margin:0px;line-height:normal"> Line One\</div><div style="margin:0px;line-height:normal"> Line Two\</div><div style="margin:0px;line-height:normal"> """<span style="color:rgb(0,0,0)"> </span><span style="text-decoration:underline;color:rgb(0,0,0)">=</span><span style="color:rgb(0,0,0)">= </span>"Line One\\\nLineTwo\\"</div><div><br></div><div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">I had considered another version of the proposal where known escapes</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">were still processed but it proved too difficult to reason exactly what was</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">contained in the string.</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">There is a example toolchain available for testing:</div></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div></div></div></div></div></div><div><a href="http://johnholdsworth.com/swift-LOCAL-2017-11-23-a-osx.tar.gz" target="_blank">http://johnholdsworth.com/<wbr>swift-LOCAL-2017-11-23-a-osx.<wbr>tar.gz</a></div><div><br></div><div>Can we shepard this minor additive change into Swift 4.1?</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>John</div></font></span></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div></div></div></div>