[swift-evolution] URL Literals

[Xiaodi Wu]

On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via swift-evolution <
swift-evolution at swift.org> wrote:

> As an aide to learning I've been playing around with implementation of
> some of these concepts in the compiler and a few things popped up that
> I'm not happy with.
>
> First, regarding the way #fileLiteral works, it necessitates the
> addition of URL.init(fileReferenceLiteralResourceName:) which takes a
> string but does not return an optional value. Fine, except that I
> don't have to call #fileLiteral in my code to use that constructor, I
> can also use it directly. While I could get compile-time checking on
> the #fileLiteral, I can't on the direct constructor. Additionally, I
> could use the direct constructor with any String, not just literals.
> Internally that will call ```self = Bundle.main.url(forResource: name,
> withExtension: nil)!``` and crash at runtime if it's not found.
> Clearly we do not intend that init to be called directly, but that
> isn't clear to new Swift user Jude Doe, who discovers the API as xe
> autocompletes from Xcode.
>

That could be fixed with documentation. This API design was reviewed and
approved as part of SE-0039:
https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md


> The second problem comes from String Interpolation. It's a basic
> problem I think with anything that extends the concept of the
> string_literal with additional requirements that need to be checked at
> compile-time. Right now I can put in something like
> ```#fileLiteral(resourceName: "\(myString)")```.


Can you? SE-0039 says that resourceName should be a static-string-literal,
which (unless I'm mistaken) should forbid interpolation.


> While at one level it
> might seem nice to be able to construct this sort of thing, it's not
> at all nice from a validation perspective.
>
> I think this has to be solved at a higher level, in the Lexer, making
> a url literal a concept at that level, and fundamentally NOT a string
> literal underneath, even if they shared some similar constructs.
>
> The Lexer would be able to see #url("https://\(host)") and say
> "Invalid escape sequence in literal, \( is not understood as a url".
> In fact, the URL literal should probably not need ANY escape sequences
> or even the concept of escape sequences, since a double-quote is not a
> legal character in a URL.
>
> I definitely think we should take this opportunity to identify that we
> do NOT want to use string literal as it currently stands as a base
> construct for other literal types. Quite possibly there's another,
> more restricted concept that we can draw out of string literal that
> would make a good base construct, but certainly not a string literal
> with interpolation.
>
>
>
>
> On Wed, Dec 28, 2016 at 8:01 AM, Jonathan Hull via swift-evolution
> <swift-evolution at swift.org> wrote:
> >
> > On Dec 27, 2016, at 11:46 AM, David Sweeris <davesweeris at mac.com> wrote:
> >
> >
> > On Dec 22, 2016, at 11:39 PM, Jonathan Hull <jhull at gbis.com> wrote:
> >
> >
> > On Dec 20, 2016, at 12:29 PM, David Sweeris <davesweeris at mac.com> wrote:
> >
> >
> > On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution
> > <swift-evolution at swift.org> wrote:
> >
> > Yes, I agree.  I am excited to see what happens in phase 2.
> >
> > What I am suggesting here is slightly different. Basically being able to
> use
> > RegEx (with capture groups) as a shorthand for a type composed of base
> > literals. For example: (StringLiteral, [IntegerLiteral]). Named capture
> > groups could even map to a dictionary literal.  I am using “RegEx goes
> Here”
> > to represent RegEx in the examples below, but hopefully it will get it’s
> own
> > literal type in Xcode (Imagine that replacing it here).
> >
> > func foo( _ param: “RegExGoesHere”) {…} //Definition uses a RegEx where
> the
> > type would normally be
> > foo(“my parseable string") //Calling with a string literal
> >
> > In this case, ‘param’ takes a string literal when called but the compiler
> > converts it to a tuple of literals based on the regEx supplied and passes
> > that tuple the function. The type/structure of the tuple is defined by
> the
> > capture groups in the RegEx
> >
> > The parameter above would only allow string literals to be passed in, and
> > would give a compiler error if you tried to pass a variable or if the
> string
> > didn’t conform to the supplied RegEx.  To allow passing String variables
> you
> > would have to add either ‘?’ or ‘!’ after the RegEx definition to handle
> the
> > case where the value doesn’t conform.
> >
> > func foo( _ param: “RegExGoesHere”?) {…} //‘param' is nil if RegEx fails
> > foo(myStringVar) //Calling
> >
> > func bar( _ param: “RegExGoesHere”!) {…} //fatal error if RegEx fails
> >
> > When a variable is passed, the RegEx is performed at runtime instead of
> > compile time.
> >
> > Once you have this, the syntax to add new literal types/initializers
> falls
> > out virtually for free.
> >
> >
> > Is “RegExGoesHere” where the regex pattern goes, or where the string
> you’re
> > trying to match goes? If it’s the latter, where does the pattern go? If
> it’s
> > the former, where does the string you’re trying to match go?
> >
> >
> > “RegExGoesHere” is where the pattern goes (instead of the type).  The
> string
> > you are trying to match gets passed in as the parameter (e.g. “my
> parseable
> > string”).
> >
> > Ah, ok, I think I understand what you’re saying now... You’re suggesting
> > that instead of defining a custom type that conforms to “RegExLiteral”
> (or
> > some other mechanism) and using that as the parameter’s type, you put
> your
> > regex pattern as the type directly?
> >
> >
> > Yes.  It is admittedly an advanced feature, but I think it would be a
> useful
> > one.
> >
> > Thanks,
> > Jon
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161228/8850140c/attachment.html>