<div dir="ltr">On Sat, Nov 25, 2017 at 12:08 AM, 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"><br><div><span class=""><br><blockquote type="cite"><div>On Nov 24, 2017, at 7:52 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="m_-1245455392111515672Apple-interchange-newline"><div><blockquote class="gmail_quote" 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;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;line-break:after-white-space"><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 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">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 ExpressibleByRegularExpression<wbr>Literal.</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"><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">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. </div></div></blockquote><div><br></div></span><div>Right, but the string literal syntaxes we have (single and multiline) do not allow different grammars (e.g. escape sequences) depending on what type they are inferred to.  Wouldn’t it be odd if a string literal accepted “\x12\u1212\U00001212” when it converts to a &quot;const char *” but accepted “\u{12345}” when passed to a bridged Dart API?</div></div></div></blockquote><div><br></div><div>...And here we come full circle. The original proposal is precisely to have a different type of string literal that accepts/rejects different escape sequences. In my initial reply, I wrote that (should raw strings be sufficiently motivated that some sort of solution is clearly desirable) one avenue to explore is redesigning literals to allow conforming types to access the &quot;raw&quot; literal, free of all but the most minimal processing, so that the type can choose the grammar rather than the literal. In so doing, we avoid having to hardcode new &quot;flavors&quot; of string literal.</div><div><br></div><div>It is precisely in observing these repeated requests for now flavors of string literals, as well as existing shortcomings of integer and float literals for supporting BigInt and Decimal types, that leads me to think that we should exactly allow what you describe as &quot;odd.&quot;</div><div><br></div></div></div></div>