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...@gmail.com> wrote: > On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline <micah.hainl...@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@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...@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...@gmail.com> wrote: >> >> >> >> PR #6503. Turned out to be trivial. >> >> >> >> On Wed, Dec 28, 2016 at 4:38 PM, Xiaodi Wu <xiaodi...@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.hainl...@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...@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...@gmail.com> >> >>>> > wrote: >> >>>> >> >> >>>> >> Well, let's stop that :) >> >>>> >> >> >>>> >> >> >>>> >> On Wed, Dec 28, 2016 at 3:21 PM, Micah Hainline >> >>>> >> <micah.hainl...@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.hainl...@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...@gmail.com> >> >>>> >>> > wrote: >> >>>> >>> >> Does it run? >> >>>> >>> >> >> >>>> >>> >> On Wed, Dec 28, 2016 at 3:10 PM, Micah Hainline >> >>>> >>> >> <micah.hainl...@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...@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@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...@gmail.com> >> >>>> >> >>>> >>> >>> >> wrote: >> >>>> >>> >>> >> > On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via >> >>>> >>> >>> >> > swift-evolution >> >>>> >>> >>> >> > <swift-evolution@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...@gmail.com> >> >>>> >>> >>> >> >> wrote: >> >>>> >>> >>> >> >> > On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via >> >>>> >>> >>> >> >> > swift-evolution >> >>>> >>> >>> >> >> > <swift-evolution@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@swift.org> wrote: >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > On Dec 27, 2016, at 11:46 AM, David Sweeris >> >>>> >>> >>> >> >> >> > <daveswee...@mac.com> >> >>>> >>> >>> >> >> >> > wrote: >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > On Dec 22, 2016, at 11:39 PM, Jonathan Hull >> >>>> >>> >>> >> >> >> > <jh...@gbis.com> >> >>>> >>> >>> >> >> >> > wrote: >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > On Dec 20, 2016, at 12:29 PM, David Sweeris >> >>>> >>> >>> >> >> >> > <daveswee...@mac.com> >> >>>> >>> >>> >> >> >> > wrote: >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > On Dec 20, 2016, at 2:11 AM, Jonathan Hull via >> >>>> >>> >>> >> >> >> > swift-evolution >> >>>> >>> >>> >> >> >> > <swift-evolution@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@swift.org >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> > https://lists.swift.org/mailma >> n/listinfo/swift-evolution >> >>>> >>> >>> >> >> >> > >> >>>> >>> >>> >> >> >> _______________________________________________ >> >>>> >>> >>> >> >> >> swift-evolution mailing list >> >>>> >>> >>> >> >> >> swift-evolution@swift.org >> >>>> >>> >>> >> >> >> >> >>>> >>> >>> >> >> >> https://lists.swift.org/mailma >> n/listinfo/swift-evolution >> >>>> >>> >>> >> >> > >> >>>> >>> >>> >> >> > >> >>>> >>> >>> >> >> _______________________________________________ >> >>>> >>> >>> >> >> swift-evolution mailing list >> >>>> >>> >>> >> >> swift-evolution@swift.org >> >>>> >>> >>> >> >> https://lists.swift.org/mailma >> n/listinfo/swift-evolution >> >>>> >>> >>> >> > >> >>>> >>> >>> >> > >> >>>> >>> >>> >> _______________________________________________ >> >>>> >>> >>> >> swift-evolution mailing list >> >>>> >>> >>> >> swift-evolution@swift.org >> >>>> >>> >>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>>> >>> >>> > >> >>>> >>> >>> > >> >>>> >>> >> >> >>>> >>> >> >> >>>> >> >> >>>> >> >> >>>> > >> >>> >> >>> >> >> >> > >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution