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