<div dir="ltr">On Wed, Dec 28, 2016 at 2:08 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">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></blockquote><div><br></div><div>That could be fixed with documentation. This API design was reviewed and approved as part of SE-0039:</div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md">https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md</a></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">
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)")```.</blockquote><div><br></div><div>Can you? SE-0039 says that resourceName should be a static-string-literal, which (unless I'm mistaken) should forbid interpolation.</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">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>
<div class="gmail-HOEnZb"><div class="gmail-h5"><<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 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 Here”<br>
> to represent RegEx in the examples below, but hopefully it will get it’s own<br>
> literal type in Xcode (Imagine that replacing it here).<br>
><br>
> func foo( _ param: “RegExGoesHere”) {…} //Definition uses a RegEx where 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 compiler<br>
> converts it to a tuple of literals based on the regEx supplied and passes<br>
> that tuple the function. The type/structure of the tuple is defined by the<br>
> capture groups in the RegEx<br>
><br>
> The parameter above would only allow string literals to be passed in, and<br>
> would give a compiler error if you tried to pass a variable or if the string<br>
> didn’t conform to the supplied RegEx. To allow passing String variables you<br>
> would have to add either ‘?’ or ‘!’ after the RegEx definition to handle 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 falls<br>
> out virtually for free.<br>
><br>
><br>
> Is “RegExGoesHere” where the regex pattern goes, or where the string you’re<br>
> trying to match goes? If it’s the latter, where does the pattern go? If 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 string<br>
> you are trying to match gets passed in as the parameter (e.g. “my 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” (or<br>
> some other mechanism) and using that as the parameter’s type, you put 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 useful<br>
> one.<br>
><br>
> Thanks,<br>
> Jon<br>
><br>
><br>
><br>
</div></div><div class="gmail-HOEnZb"><div class="gmail-h5">> ______________________________<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>
</div></div></blockquote></div><br></div></div>