[swift-evolution] URL Literals

Thu Dec 29 15:25:09 CST 2016

I think for me, the big difference between a color literal and URL literal,
which swayed me in the end was this:

As noted in SE-0039, `[#Color(...)#]` (now `#colorLiteral(...)`) isn't
itself a literal; it's a spelling that allows you to _get_ a literal, which
is a swatch of color. On reflection, whether these things ought to be
termed "literals" exactly like strings is something maybe worth revisiting.
They certainly have benefits (_seeing_ a color is nice), but still,
consider how they differ from string literals, etc:

To me at least, `"foo"` _is_ literally a string and `0` is literally an
integer, both of no particular type until it's assigned to a variable,
which is what literals make possible. By the same token, almost any power
user of computers can recognize that `<http://google.com/>` _is_ literally
a URL and `/regex/` _is_ literally a regular expression. I'll call these
"true literals" for the moment. There are, naturally, a limited number of
true literals in the world, and that upper bound is not an artificial limit
of any programming language. For that reason, I think we ought not be
concerned about "running out" of delimiters.

Even as I continue to believe that a constexpr-like facility might be the
best holistic solution for those who need compile-time validation of custom
types, I can now see that there are grounds to regard a URL as something
special, a true literal for which there is a rational basis for first-class
support from the compiler.

On Thu, Dec 29, 2016 at 3:49 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline <micah.hainline at gmail.com>
> wrote:
>
>> 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.
>
>
> True, but I doubt that's a common use case. JavaScript supports `/regex/`
> and I haven't heard of complaints re not supporting `//`.
>
>
>> 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.
>>
>
> Besides being a natural way of writing it, < and > have the advantage that
> resolving their different uses is already heavily tested (because generics
> use <>, and because the lexer understands merging artifacts like <<<<<< and
> >>>>>>).
>
>
>> 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...
>>
>
> To me, that's a feature, not a bug. I'd argue that the language should
> provide first-class support for only a few, very important literals (like
> strings). Compile time validation for arbitrary types, as I've said before,
> should probably be solved in other, more holistic ways (such as some sort
> of constexpr-like feature).
>
> 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 #.
>
>
> We had that before, essentially. Object literals (file, image, color) were
> spelled like this: [#Color(...)#]. They were removed with SE-0039.
>
>
> 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(fileReferenceLiteralR
>> esourceName:)
>> >>>> >>> >>> >> >> >> 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/mailma
>> n/listinfo/swift-evolution
>> >>>> >>> >>> >> >> >> >
>> >>>> >>> >>> >> >> >> _______________________________________________
>> >>>> >>> >>> >> >> >> swift-evolution mailing list
>> >>>> >>> >>> >> >> >> swift-evolution at swift.org
>> >>>> >>> >>> >> >> >>
>> >>>> >>> >>> >> >> >> https://lists.swift.org/mailma
>> n/listinfo/swift-evolution
>> >>>> >>> >>> >> >> >
>> >>>> >>> >>> >> >> >
>> >>>> >>> >>> >> >> _______________________________________________
>> >>>> >>> >>> >> >> swift-evolution mailing list
>> >>>> >>> >>> >> >> swift-evolution at swift.org
>> >>>> >>> >>> >> >> https://lists.swift.org/mailma
>> n/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/20161229/918d4e54/attachment.html>