<div dir="ltr">On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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"><span class="gmail-">&gt; SE-0039 says that resourceName should be a static-string-literal<br>
<br>
</span>It compiles just fine for me in my project. My next question was going<br>
to be do we actually need a change in the language spec, or can we<br>
call fixing that a bug, I think you&#39;re answering my question for me<br>
before I even had to ask it!</blockquote><div><br></div><div>I&#39;d call that a bug. It doesn&#39;t run, and there&#39;s no reason why something not allowed by the grammar shouldn&#39;t be diagnosed at compile time, IMO.</div><div><br></div><div>From _The Swift Programming Language_:</div><div><br></div><div><div>GRAMMAR OF A STRING LITERAL</div><div>string-literal → static-string-literal­ | interpolated-string-literal­</div><div>static-string-literal → &quot;­quoted-text­opt­&quot;­</div><div>quoted-text → quoted-text-item­ quoted-text­opt­</div><div>quoted-text-item → escaped-character­</div><div>quoted-text-item → Any Unicode scalar value except &quot;­, \­, U+000A, or U+000D</div><div>interpolated-string-literal → &quot;­interpolated-text­opt­&quot;­</div><div>interpolated-text → interpolated-text-item­ interpolated-text­opt­</div><div>interpolated-text-item → \(­expression­)­ | quoted-text-item­</div><div>escaped-character → \0­ | \\­ | \t­ | \n­ | \r­ | \&quot;­ | \&#39;­</div><div>escaped-character → \u­{­unicode-scalar-digits­}­</div><div>unicode-scalar-digits → Between one and eight hexadecimal digit</div></div><div><br></div><div> </div><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 class="gmail-HOEnZb"><div class="gmail-h5">
On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt; On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via swift-evolution<br>
&gt; &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; As an aide to learning I&#39;ve been playing around with implementation of<br>
&gt;&gt; some of these concepts in the compiler and a few things popped up that<br>
&gt;&gt; I&#39;m not happy with.<br>
&gt;&gt;<br>
&gt;&gt; First, regarding the way #fileLiteral works, it necessitates the<br>
&gt;&gt; addition of URL.init(<wbr>fileReferenceLiteralResourceNa<wbr>me:) which takes a<br>
&gt;&gt; string but does not return an optional value. Fine, except that I<br>
&gt;&gt; don&#39;t have to call #fileLiteral in my code to use that constructor, I<br>
&gt;&gt; can also use it directly. While I could get compile-time checking on<br>
&gt;&gt; the #fileLiteral, I can&#39;t on the direct constructor. Additionally, I<br>
&gt;&gt; could use the direct constructor with any String, not just literals.<br>
&gt;&gt; Internally that will call ```self = Bundle.main.url(forResource: name,<br>
&gt;&gt; withExtension: nil)!``` and crash at runtime if it&#39;s not found.<br>
&gt;&gt; Clearly we do not intend that init to be called directly, but that<br>
&gt;&gt; isn&#39;t clear to new Swift user Jude Doe, who discovers the API as xe<br>
&gt;&gt; autocompletes from Xcode.<br>
&gt;<br>
&gt;<br>
&gt; That could be fixed with documentation. This API design was reviewed and<br>
&gt; approved as part of SE-0039:<br>
&gt; <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0039-<wbr>playgroundliterals.md</a><br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; The second problem comes from String Interpolation. It&#39;s a basic<br>
&gt;&gt; problem I think with anything that extends the concept of the<br>
&gt;&gt; string_literal with additional requirements that need to be checked at<br>
&gt;&gt; compile-time. Right now I can put in something like<br>
&gt;&gt; ```#fileLiteral(resourceName: &quot;\(myString)&quot;)```.<br>
&gt;<br>
&gt;<br>
&gt; Can you? SE-0039 says that resourceName should be a static-string-literal,<br>
&gt; which (unless I&#39;m mistaken) should forbid interpolation.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; While at one level it<br>
&gt;&gt; might seem nice to be able to construct this sort of thing, it&#39;s not<br>
&gt;&gt; at all nice from a validation perspective.<br>
&gt;&gt;<br>
&gt;&gt; I think this has to be solved at a higher level, in the Lexer, making<br>
&gt;&gt; a url literal a concept at that level, and fundamentally NOT a string<br>
&gt;&gt; literal underneath, even if they shared some similar constructs.<br>
&gt;&gt;<br>
&gt;&gt; The Lexer would be able to see #url(&quot;https://\(host)&quot;) and say<br>
&gt;&gt; &quot;Invalid escape sequence in literal, \( is not understood as a url&quot;.<br>
&gt;&gt; In fact, the URL literal should probably not need ANY escape sequences<br>
&gt;&gt; or even the concept of escape sequences, since a double-quote is not a<br>
&gt;&gt; legal character in a URL.<br>
&gt;&gt;<br>
&gt;&gt; I definitely think we should take this opportunity to identify that we<br>
&gt;&gt; do NOT want to use string literal as it currently stands as a base<br>
&gt;&gt; construct for other literal types. Quite possibly there&#39;s another,<br>
&gt;&gt; more restricted concept that we can draw out of string literal that<br>
&gt;&gt; would make a good base construct, but certainly not a string literal<br>
&gt;&gt; with interpolation.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Dec 28, 2016 at 8:01 AM, Jonathan Hull via swift-evolution<br>
&gt;&gt; &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Dec 27, 2016, at 11:46 AM, David Sweeris &lt;<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Dec 22, 2016, at 11:39 PM, Jonathan Hull &lt;<a href="mailto:jhull@gbis.com">jhull@gbis.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Dec 20, 2016, at 12:29 PM, David Sweeris &lt;<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution<br>
&gt;&gt; &gt; &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes, I agree.  I am excited to see what happens in phase 2.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What I am suggesting here is slightly different. Basically being able to<br>
&gt;&gt; &gt; use<br>
&gt;&gt; &gt; RegEx (with capture groups) as a shorthand for a type composed of base<br>
&gt;&gt; &gt; literals. For example: (StringLiteral, [IntegerLiteral]). Named capture<br>
&gt;&gt; &gt; groups could even map to a dictionary literal.  I am using “RegEx goes<br>
&gt;&gt; &gt; Here”<br>
&gt;&gt; &gt; to represent RegEx in the examples below, but hopefully it will get it’s<br>
&gt;&gt; &gt; own<br>
&gt;&gt; &gt; literal type in Xcode (Imagine that replacing it here).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; func foo( _ param: “RegExGoesHere”) {…} //Definition uses a RegEx where<br>
&gt;&gt; &gt; the<br>
&gt;&gt; &gt; type would normally be<br>
&gt;&gt; &gt; foo(“my parseable string&quot;) //Calling with a string literal<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; In this case, ‘param’ takes a string literal when called but the<br>
&gt;&gt; &gt; compiler<br>
&gt;&gt; &gt; converts it to a tuple of literals based on the regEx supplied and<br>
&gt;&gt; &gt; passes<br>
&gt;&gt; &gt; that tuple the function. The type/structure of the tuple is defined by<br>
&gt;&gt; &gt; the<br>
&gt;&gt; &gt; capture groups in the RegEx<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The parameter above would only allow string literals to be passed in,<br>
&gt;&gt; &gt; and<br>
&gt;&gt; &gt; would give a compiler error if you tried to pass a variable or if the<br>
&gt;&gt; &gt; string<br>
&gt;&gt; &gt; didn’t conform to the supplied RegEx.  To allow passing String variables<br>
&gt;&gt; &gt; you<br>
&gt;&gt; &gt; would have to add either ‘?’ or ‘!’ after the RegEx definition to handle<br>
&gt;&gt; &gt; the<br>
&gt;&gt; &gt; case where the value doesn’t conform.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; func foo( _ param: “RegExGoesHere”?) {…} //‘param&#39; is nil if RegEx fails<br>
&gt;&gt; &gt; foo(myStringVar) //Calling<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; func bar( _ param: “RegExGoesHere”!) {…} //fatal error if RegEx fails<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; When a variable is passed, the RegEx is performed at runtime instead of<br>
&gt;&gt; &gt; compile time.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Once you have this, the syntax to add new literal types/initializers<br>
&gt;&gt; &gt; falls<br>
&gt;&gt; &gt; out virtually for free.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Is “RegExGoesHere” where the regex pattern goes, or where the string<br>
&gt;&gt; &gt; you’re<br>
&gt;&gt; &gt; trying to match goes? If it’s the latter, where does the pattern go? If<br>
&gt;&gt; &gt; it’s<br>
&gt;&gt; &gt; the former, where does the string you’re trying to match go?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; “RegExGoesHere” is where the pattern goes (instead of the type).  The<br>
&gt;&gt; &gt; string<br>
&gt;&gt; &gt; you are trying to match gets passed in as the parameter (e.g. “my<br>
&gt;&gt; &gt; parseable<br>
&gt;&gt; &gt; string”).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Ah, ok, I think I understand what you’re saying now... You’re suggesting<br>
&gt;&gt; &gt; that instead of defining a custom type that conforms to “RegExLiteral”<br>
&gt;&gt; &gt; (or<br>
&gt;&gt; &gt; some other mechanism) and using that as the parameter’s type, you put<br>
&gt;&gt; &gt; your<br>
&gt;&gt; &gt; regex pattern as the type directly?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes.  It is admittedly an advanced feature, but I think it would be a<br>
&gt;&gt; &gt; useful<br>
&gt;&gt; &gt; one.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt; Jon<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; ______________________________<wbr>_________________<br>
&gt;&gt; &gt; swift-evolution mailing list<br>
&gt;&gt; &gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt; &gt; <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>
&gt;&gt; &gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt; <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>
&gt;<br>
&gt;<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>
</div></div></blockquote></div><br></div></div>