[swift-evolution] URL Literals

Thu Dec 29 14:49:09 CST 2016

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(fileReferenceLiteralResourceNa
> me:)
> >>>> >>> >>> >> >> >> 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
> >>>> >>> >>> >
> >>>> >>> >>> >
> >>>> >>> >>
> >>>> >>> >>
> >>>> >>
> >>>> >>
> >>>> >
> >>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161229/cec2eb8b/attachment.html>