[swift-evolution] URL Literals

Thu Dec 29 14:18:34 CST 2016

I think that's all doable. I'm not sure what delimiters would be the
best though, which is why I hadn't moved away from #url yet. I've been
thinking hard about the regex, which seems like an even stronger case
to make into a literal, and /abc/ works well for those, but even those
have some problems, as an empty regex (valid according to
NSRegularExpression) of // would parse also as a comment. For < and >
it could start getting confusing with overloaded operators. I think it
would work, but could be a little trickier than it seems like on first
blush.

It would be easier to lex if it were expressed like
#url<https://example.com>, but ease of lexing probably doesn't weigh
that heavily. If we wanted to do more than string, url, and regex we'd
start running out of delimiters fast though...

Another idea (taking from ruby a little) would be to have something
like %url{https://example.com} and %regex{my/regex}

In ruby, their %r{} structure can take things other than {} as long as
they don't appear in the string (for instance %r at my/regex@ works too),
we could do something like that and have a pretty robust structure for
whatever literals we wanted going forward, and it should work for url
and regex, which are in the more immediate future. Of course, % could
just as easily be #.

On Thu, Dec 29, 2016 at 12:37 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> Micah,
>
> I think I'm coming round to your line of thinking re URL literals. It'd be
> nice to have them supported first-class, not like image literals (the design
> for which is really geared towards playgrounds and is rather hacky, IMO),
> but like strings. In that scenario, Foundation URL would conform to
> ExpressibleByURLLiteral. URL could even be the default URLLiteralType once
> Foundation is imported (just like String is the default StringLiteralType).
>
> What'd be _really_ nice, though, is to solidify the first-class status of
> URL literals by their spelling: not `#urlLiteral(resourceName: "blahblah")`
> or even `#url("blahblah")`, but just as you write `let str = "this is a
> string"` (and I'm sure we'll have `let regex = /foo/`), we should have `let
> url = <https://google.com/>`. The compiler would ensure that what's between
> the delimiters is a valid relative or absolute URL, and `init(urlLiteral:)`
> will get a parsed tuple just as the official standard outlines, with scheme,
> username, password, host, port, cannot-be-a-base-URL flag, path, query,
> fragment all ready to go. Looking through the lexer, it seems like this
> _should_ be possible and not inordinate amounts of work. Any thoughts about
> this idea, since you're actively studying the lexer?
>
> Xiaodi
>
>
> On Wed, Dec 28, 2016 at 5:18 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> PR #6503. Turned out to be trivial.
>>
>> On Wed, Dec 28, 2016 at 4:38 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> Not yet, still building locally. My computer's slow. There's one problem
>>> that's apparent though. Here's an existing test in the repo:
>>>
>>> ```
>>> LiteralsTestSuite.test("image") {
>>>   let image = #imageLiteral(resourceName: NSImageNameComputer)
>>>   expectTrue(image.isValid)
>>> }
>>> ```
>>>
>>> Unfortunately, although `NSImageNameComputer` is a constant, it's of type
>>> `String`. And tweaking global Obj-C bridging rules so that `NSString *
>>> const` comes through as `StaticString` is just not gonna happen, because of
>>> all the things you'd break. We'll lose this (kinda useful) use of
>>> #imageLiteral unless someone goes ahead and manually bridges the
>>> NSImageName* constants, which is acceptable, I suppose. That someone would
>>> have to be the Foundation team, because Foundation APIs aren't really
>>> subject to Evolution.
>>>
>>>
>>> On Wed, Dec 28, 2016 at 4:29 PM, Micah Hainline
>>> <micah.hainline at gmail.com> wrote:
>>>>
>>>> Do you have it checked in somewhere I can see it?
>>>>
>>>> On Wed, Dec 28, 2016 at 2:51 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>> > I may be wrong, but I think I've fixed it. Will test and make sure.
>>>> >
>>>> > On Wed, Dec 28, 2016 at 3:22 PM, Xiaodi Wu <xiaodi.wu at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Well, let's stop that :)
>>>> >>
>>>> >>
>>>> >> On Wed, Dec 28, 2016 at 3:21 PM, Micah Hainline
>>>> >> <micah.hainline at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Yep, compiles, runs, no warnings or errors and the program displays
>>>> >>> the expected results.
>>>> >>>
>>>> >>> On Wed, Dec 28, 2016 at 2:12 PM, Micah Hainline
>>>> >>> <micah.hainline at gmail.com> wrote:
>>>> >>> > Good question. It certainly compiles, but I've stuck it in an
>>>> >>> > out-of-the-way spot, I'll need to create a test project to know
>>>> >>> > the
>>>> >>> > answer to that. Just FYI: https://bugs.swift.org/browse/SR-3504
>>>> >>> >
>>>> >>> >
>>>> >>> > On Wed, Dec 28, 2016 at 2:11 PM, Xiaodi Wu <xiaodi.wu at gmail.com>
>>>> >>> > wrote:
>>>> >>> >> Does it run?
>>>> >>> >>
>>>> >>> >> On Wed, Dec 28, 2016 at 3:10 PM, Micah Hainline
>>>> >>> >> <micah.hainline at gmail.com>
>>>> >>> >> wrote:
>>>> >>> >>>
>>>> >>> >>> I'm doing it in a normal project rather than a playground.
>>>> >>> >>>
>>>> >>> >>> On Wed, Dec 28, 2016 at 1:50 PM, Xiaodi Wu <xiaodi.wu at gmail.com>
>>>> >>> >>> wrote:
>>>> >>> >>> > Offlist--
>>>> >>> >>> >
>>>> >>> >>> > In a playground, I get a runtime error when I move the string
>>>> >>> >>> > into
>>>> >>> >>> > a
>>>> >>> >>> > variable and write `#fileLiteral(resourceName: "\(myVar)")`.
>>>> >>> >>> > Could
>>>> >>> >>> > be
>>>> >>> >>> > doing
>>>> >>> >>> > it wrong though.
>>>> >>> >>> >
>>>> >>> >>> > I'll submit a PR to document that users should not use the
>>>> >>> >>> > technically
>>>> >>> >>> > public APIs for literals.
>>>> >>> >>> >
>>>> >>> >>> >
>>>> >>> >>> > On Wed, Dec 28, 2016 at 2:44 PM, Micah Hainline via
>>>> >>> >>> > swift-evolution
>>>> >>> >>> > <swift-evolution at swift.org> wrote:
>>>> >>> >>> >>
>>>> >>> >>> >> I think the way it's set up it probably WOULD run, but it
>>>> >>> >>> >> should
>>>> >>> >>> >> still
>>>> >>> >>> >> probably be a compile error. I like that we have the concept
>>>> >>> >>> >> of
>>>> >>> >>> >> static-string-literal in the language definition, but I'm
>>>> >>> >>> >> having a
>>>> >>> >>> >> bit
>>>> >>> >>> >> of a hard time tracking it through the compiler. Of course,
>>>> >>> >>> >> these
>>>> >>> >>> >> are
>>>> >>> >>> >> problems probably not right for this list, so I'll take them
>>>> >>> >>> >> into
>>>> >>> >>> >> a
>>>> >>> >>> >> bug instead.
>>>> >>> >>> >>
>>>> >>> >>> >> On Wed, Dec 28, 2016 at 1:36 PM, Xiaodi Wu
>>>> >>> >>> >> <xiaodi.wu at gmail.com>
>>>>
>>>> >>> >>> >> wrote:
>>>> >>> >>> >> > On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via
>>>> >>> >>> >> > swift-evolution
>>>> >>> >>> >> > <swift-evolution at swift.org> wrote:
>>>> >>> >>> >> >>
>>>> >>> >>> >> >> > SE-0039 says that resourceName should be a
>>>> >>> >>> >> >> > static-string-literal
>>>> >>> >>> >> >>
>>>> >>> >>> >> >> It compiles just fine for me in my project. My next
>>>> >>> >>> >> >> question
>>>> >>> >>> >> >> was
>>>> >>> >>> >> >> going
>>>> >>> >>> >> >> to be do we actually need a change in the language spec,
>>>> >>> >>> >> >> or can
>>>> >>> >>> >> >> we
>>>> >>> >>> >> >> call fixing that a bug, I think you're answering my
>>>> >>> >>> >> >> question
>>>> >>> >>> >> >> for me
>>>> >>> >>> >> >> before I even had to ask it!
>>>> >>> >>> >> >
>>>> >>> >>> >> >
>>>> >>> >>> >> > 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.
>>>> >>> >>> >> >
>>>> >>> >>> >> > From _The Swift Programming Language_:
>>>> >>> >>> >> >
>>>> >>> >>> >> > GRAMMAR OF A STRING LITERAL
>>>> >>> >>> >> > string-literal → static-string-literal |
>>>> >>> >>> >> > interpolated-string-literal
>>>> >>> >>> >> > static-string-literal → "quoted-textopt"
>>>> >>> >>> >> > quoted-text → quoted-text-item quoted-textopt
>>>> >>> >>> >> > quoted-text-item → escaped-character
>>>> >>> >>> >> > quoted-text-item → Any Unicode scalar value except ", \,
>>>> >>> >>> >> > U+000A, or
>>>> >>> >>> >> > U+000D
>>>> >>> >>> >> > interpolated-string-literal → "interpolated-textopt"
>>>> >>> >>> >> > interpolated-text → interpolated-text-item
>>>> >>> >>> >> > interpolated-textopt
>>>> >>> >>> >> > interpolated-text-item → \(expression) |
>>>> >>> >>> >> > quoted-text-item
>>>> >>> >>> >> > escaped-character → \0 | \\ | \t | \n | \r | \" | \'
>>>> >>> >>> >> > escaped-character → \u{unicode-scalar-digits}
>>>> >>> >>> >> > unicode-scalar-digits → Between one and eight hexadecimal
>>>> >>> >>> >> > digit
>>>> >>> >>> >> >
>>>> >>> >>> >> >
>>>> >>> >>> >> >>
>>>> >>> >>> >> >> On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu
>>>> >>> >>> >> >> <xiaodi.wu at gmail.com>
>>>> >>> >>> >> >> wrote:
>>>> >>> >>> >> >> > 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
>>>> >>> >>> >> >> >
>>>> >>> >>> >> >> >
>>>> >>> >>> >> >> _______________________________________________
>>>> >>> >>> >> >> 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
>>>> >>> >>> >
>>>> >>> >>> >
>>>> >>> >>
>>>> >>> >>
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>
>