<div dir="ltr">On Fri, Nov 24, 2017 at 6:25 PM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><span class=""><br><div><br><blockquote type="cite"><div>On Nov 24, 2017, at 4:15 PM, Chris Lattner &lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt; wrote:</div><br class="m_3952593285953842737Apple-interchange-newline"><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br class="m_3952593285953842737Apple-interchange-newline">than the same type having a collection of named matches using the usual Perl syntax?</div><div><br></div><div>  if case /(?&lt;firstName&gt;[a-zA-Z]+) (?&lt;lastName&gt;[a-zA-Z]+)/ = getSomeString() {</div><div>    print(Regex.captured[&quot;<wbr>firstName&quot;], Regex.captured[&quot;lastName&quot;])</div><div>  }</div></div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Personally, I really don’t like this.  It turns a structured problem into one that violates DRY and loses the structure inherent in the solution.  Also, while theoretically the dictionary could be optimized away, in practice that would be difficult to do without heroics.</div><br class="m_3952593285953842737Apple-interchange-newline"></div></blockquote></div><br></span><div>One other minor and obscure point: if the compiler is aware of the regex grammar it can properly type the matches, I can imagine the following cases:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>if case /(let name: [a-zA-Z]+) (let count: Int)/ = getSomeString() {</div><div>   print(name, count)</div><div>}</div></blockquote><div><br></div><div>-&gt; name has type String, count has type Int (and matches [0-9]+)</div><div><br></div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>if case /(let name: [a-zA-Z]+)? (let count: Int)/ = getSomeString() {</div><div>   print(name, count)</div><div>}</div><div><br></div></blockquote></div><div>-&gt; name has type String?</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>if case /(let name: [a-zA-Z]+)* (let count: Int)/ = getSomeString() {</div><div>   print(name, count)</div><div>}</div><div><br></div></blockquote>-&gt; name has type [String]</div><div><br></div><div>etc.  Even if we don’t have a “default regex” for types, it would still be awesome to be able to write:</div><div><br></div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>if case /(let name: [a-zA-Z]+) (let count: Int: [0-9]+)/ = getSomeString() {</div><div>   print(name, count)</div><div>}</div><div><br></div></blockquote></div><div>and have that transparently invoke and check the Int?(string) failable initializer.</div></div></blockquote><div><br></div><div>Yes, these are very interesting options to explore, and you&#39;re right that if we want to go down this road, then we&#39;d need to imbue regex literals with certain &quot;smarts&quot; as opposed to having lenient regex literal parsing that entirely defers validation to a concrete regex type conforming to ExpressibleByRegularExpressionLiteral.</div><div><br></div><div>I don&#39;t think it&#39;s an all-or-nothing proposition, though, as to whether the literal or the conforming type performs the validation. Personally, I think one of the strengths of Swift&#39;s literals is that they are intrinsically untyped and that multiple concrete types are expressible by them. Whether or not we think one or another regex syntax is best doesn&#39;t necessarily mean we need to preclude other regex engines from interacting with a regex literal. Rather, just like string interpolation literals allow the compiler to parse some &quot;stuff&quot; inside the quotation marks, we can have some syntax that allows for regex patterns to have segments parsed by the compiler for binding without locking down regex syntax entirely. For instance, just as the compiler parses `\(...)` inside string literals, suppose it parses `(let...)` and `(var...)` inside regex literals.</div><div><br></div></div></div></div>