<div dir="ltr">I think for me, the big difference between a color literal and URL literal, which swayed me in the end was this:<br><div><div><br></div><div>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:</div><div><br></div><div>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 `<<a href="http://google.com/">http://google.com/</a>>` _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.<br></div></div><div><br></div><div>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.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 29, 2016 at 3:49 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class="gmail-"><div>On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline <span dir="ltr"><<a href="mailto:micah.hainline@gmail.com" target="_blank">micah.hainline@gmail.com</a>></span> wrote:<br></div></span><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I think that's all doable. I'm not sure what delimiters would be the<br>
best though, which is why I hadn't moved away from #url yet. I've been<br>
thinking hard about the regex, which seems like an even stronger case<br>
to make into a literal, and /abc/ works well for those, but even those<br>
have some problems, as an empty regex (valid according to<br>
NSRegularExpression) of // would parse also as a comment.</blockquote><div><br></div></span><div>True, but I doubt that's a common use case. JavaScript supports `/regex/` and I haven't heard of complaints re not supporting `//`.</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For < and ><br>
it could start getting confusing with overloaded operators. I think it<br>
would work, but could be a little trickier than it seems like on first<br>
blush.<br></blockquote><div><br></div></span><div>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 >>>>>>).</div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It would be easier to lex if it were expressed like<br>
#url<<a href="https://example.com" rel="noreferrer" target="_blank">https://example.com</a>>, but ease of lexing probably doesn't weigh<br>
that heavily. If we wanted to do more than string, url, and regex we'd<br>
start running out of delimiters fast though...<br></blockquote><div><br></div></span><div>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).</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Another idea (taking from ruby a little) would be to have something<br>
like %url{<a href="https://example.com" rel="noreferrer" target="_blank">https://example.com</a>} and %regex{my/regex}<br>
<br>
In ruby, their %r{} structure can take things other than {} as long as<br>
they don't appear in the string (for instance %r@my/regex@ works too),<br>
we could do something like that and have a pretty robust structure for<br>
whatever literals we wanted going forward, and it should work for url<br>
and regex, which are in the more immediate future. Of course, % could<br>
just as easily be #.</blockquote><div><br></div></span><div>We had that before, essentially. Object literals (file, image, color) were spelled like this: [#Color(...)#]. They were removed with SE-0039.</div><div><div class="gmail-h5"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail-m_-5930708057526222407HOEnZb"><div class="gmail-m_-5930708057526222407h5">
On Thu, Dec 29, 2016 at 12:37 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
> Micah,<br>
><br>
> I think I'm coming round to your line of thinking re URL literals. It'd be<br>
> nice to have them supported first-class, not like image literals (the design<br>
> for which is really geared towards playgrounds and is rather hacky, IMO),<br>
> but like strings. In that scenario, Foundation URL would conform to<br>
> ExpressibleByURLLiteral. URL could even be the default URLLiteralType once<br>
> Foundation is imported (just like String is the default StringLiteralType).<br>
><br>
> What'd be _really_ nice, though, is to solidify the first-class status of<br>
> URL literals by their spelling: not `#urlLiteral(resourceName: "blahblah")`<br>
> or even `#url("blahblah")`, but just as you write `let str = "this is a<br>
> string"` (and I'm sure we'll have `let regex = /foo/`), we should have `let<br>
> url = <<a href="https://google.com/" rel="noreferrer" target="_blank">https://google.com/</a>>`. The compiler would ensure that what's between<br>
> the delimiters is a valid relative or absolute URL, and `init(urlLiteral:)`<br>
> will get a parsed tuple just as the official standard outlines, with scheme,<br>
> username, password, host, port, cannot-be-a-base-URL flag, path, query,<br>
> fragment all ready to go. Looking through the lexer, it seems like this<br>
> _should_ be possible and not inordinate amounts of work. Any thoughts about<br>
> this idea, since you're actively studying the lexer?<br>
><br>
> Xiaodi<br>
><br>
><br>
> On Wed, Dec 28, 2016 at 5:18 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
>><br>
>> PR #6503. Turned out to be trivial.<br>
>><br>
>> On Wed, Dec 28, 2016 at 4:38 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
>>><br>
>>> Not yet, still building locally. My computer's slow. There's one problem<br>
>>> that's apparent though. Here's an existing test in the repo:<br>
>>><br>
>>> ```<br>
>>> LiteralsTestSuite.test("image"<wbr>) {<br>
>>> let image = #imageLiteral(resourceName: NSImageNameComputer)<br>
>>> expectTrue(image.isValid)<br>
>>> }<br>
>>> ```<br>
>>><br>
>>> Unfortunately, although `NSImageNameComputer` is a constant, it's of type<br>
>>> `String`. And tweaking global Obj-C bridging rules so that `NSString *<br>
>>> const` comes through as `StaticString` is just not gonna happen, because of<br>
>>> all the things you'd break. We'll lose this (kinda useful) use of<br>
>>> #imageLiteral unless someone goes ahead and manually bridges the<br>
>>> NSImageName* constants, which is acceptable, I suppose. That someone would<br>
>>> have to be the Foundation team, because Foundation APIs aren't really<br>
>>> subject to Evolution.<br>
>>><br>
>>><br>
>>> On Wed, Dec 28, 2016 at 4:29 PM, Micah Hainline<br>
>>> <<a href="mailto:micah.hainline@gmail.com" target="_blank">micah.hainline@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Do you have it checked in somewhere I can see it?<br>
>>>><br>
>>>> On Wed, Dec 28, 2016 at 2:51 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
>>>> > I may be wrong, but I think I've fixed it. Will test and make sure.<br>
>>>> ><br>
>>>> > On Wed, Dec 28, 2016 at 3:22 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> Well, let's stop that :)<br>
>>>> >><br>
>>>> >><br>
>>>> >> On Wed, Dec 28, 2016 at 3:21 PM, Micah Hainline<br>
>>>> >> <<a href="mailto:micah.hainline@gmail.com" target="_blank">micah.hainline@gmail.com</a>><br>
>>>> >> wrote:<br>
>>>> >>><br>
>>>> >>> Yep, compiles, runs, no warnings or errors and the program displays<br>
>>>> >>> the expected results.<br>
>>>> >>><br>
>>>> >>> On Wed, Dec 28, 2016 at 2:12 PM, Micah Hainline<br>
>>>> >>> <<a href="mailto:micah.hainline@gmail.com" target="_blank">micah.hainline@gmail.com</a>> wrote:<br>
>>>> >>> > Good question. It certainly compiles, but I've stuck it in an<br>
>>>> >>> > out-of-the-way spot, I'll need to create a test project to know<br>
>>>> >>> > the<br>
>>>> >>> > answer to that. Just FYI: <a href="https://bugs.swift.org/browse/SR-3504" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/<wbr>SR-3504</a><br>
>>>> >>> ><br>
>>>> >>> ><br>
>>>> >>> > On Wed, Dec 28, 2016 at 2:11 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>><br>
>>>> >>> > wrote:<br>
>>>> >>> >> Does it run?<br>
>>>> >>> >><br>
>>>> >>> >> On Wed, Dec 28, 2016 at 3:10 PM, Micah Hainline<br>
>>>> >>> >> <<a href="mailto:micah.hainline@gmail.com" target="_blank">micah.hainline@gmail.com</a>><br>
>>>> >>> >> wrote:<br>
>>>> >>> >>><br>
>>>> >>> >>> I'm doing it in a normal project rather than a playground.<br>
>>>> >>> >>><br>
>>>> >>> >>> On Wed, Dec 28, 2016 at 1:50 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>><br>
>>>> >>> >>> wrote:<br>
>>>> >>> >>> > Offlist--<br>
>>>> >>> >>> ><br>
>>>> >>> >>> > In a playground, I get a runtime error when I move the string<br>
>>>> >>> >>> > into<br>
>>>> >>> >>> > a<br>
>>>> >>> >>> > variable and write `#fileLiteral(resourceName: "\(myVar)")`.<br>
>>>> >>> >>> > Could<br>
>>>> >>> >>> > be<br>
>>>> >>> >>> > doing<br>
>>>> >>> >>> > it wrong though.<br>
>>>> >>> >>> ><br>
>>>> >>> >>> > I'll submit a PR to document that users should not use the<br>
>>>> >>> >>> > technically<br>
>>>> >>> >>> > public APIs for literals.<br>
>>>> >>> >>> ><br>
>>>> >>> >>> ><br>
>>>> >>> >>> > On Wed, Dec 28, 2016 at 2:44 PM, Micah Hainline via<br>
>>>> >>> >>> > swift-evolution<br>
>>>> >>> >>> > <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>>> >>> >>> >><br>
>>>> >>> >>> >> I think the way it's set up it probably WOULD run, but it<br>
>>>> >>> >>> >> should<br>
>>>> >>> >>> >> still<br>
>>>> >>> >>> >> probably be a compile error. I like that we have the concept<br>
>>>> >>> >>> >> of<br>
>>>> >>> >>> >> static-string-literal in the language definition, but I'm<br>
>>>> >>> >>> >> having a<br>
>>>> >>> >>> >> bit<br>
>>>> >>> >>> >> of a hard time tracking it through the compiler. Of course,<br>
>>>> >>> >>> >> these<br>
>>>> >>> >>> >> are<br>
>>>> >>> >>> >> problems probably not right for this list, so I'll take them<br>
>>>> >>> >>> >> into<br>
>>>> >>> >>> >> a<br>
>>>> >>> >>> >> bug instead.<br>
>>>> >>> >>> >><br>
>>>> >>> >>> >> On Wed, Dec 28, 2016 at 1:36 PM, Xiaodi Wu<br>
>>>> >>> >>> >> <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>><br>
>>>><br>
>>>> >>> >>> >> wrote:<br>
>>>> >>> >>> >> > On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via<br>
>>>> >>> >>> >> > swift-evolution<br>
>>>> >>> >>> >> > <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>>> >>> >>> >> >><br>
>>>> >>> >>> >> >> > SE-0039 says that resourceName should be a<br>
>>>> >>> >>> >> >> > static-string-literal<br>
>>>> >>> >>> >> >><br>
>>>> >>> >>> >> >> It compiles just fine for me in my project. My next<br>
>>>> >>> >>> >> >> question<br>
>>>> >>> >>> >> >> was<br>
>>>> >>> >>> >> >> going<br>
>>>> >>> >>> >> >> to be do we actually need a change in the language spec,<br>
>>>> >>> >>> >> >> or can<br>
>>>> >>> >>> >> >> we<br>
>>>> >>> >>> >> >> call fixing that a bug, I think you're answering my<br>
>>>> >>> >>> >> >> question<br>
>>>> >>> >>> >> >> for me<br>
>>>> >>> >>> >> >> before I even had to ask it!<br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> > I'd call that a bug. It doesn't run, and there's no reason<br>
>>>> >>> >>> >> > why<br>
>>>> >>> >>> >> > something<br>
>>>> >>> >>> >> > not<br>
>>>> >>> >>> >> > allowed by the grammar shouldn't be diagnosed at compile<br>
>>>> >>> >>> >> > time,<br>
>>>> >>> >>> >> > IMO.<br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> > From _The Swift Programming Language_:<br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> > GRAMMAR OF A STRING LITERAL<br>
>>>> >>> >>> >> > string-literal → static-string-literal |<br>
>>>> >>> >>> >> > interpolated-string-literal<br>
>>>> >>> >>> >> > static-string-literal → "quoted-textopt"<br>
>>>> >>> >>> >> > quoted-text → quoted-text-item quoted-textopt<br>
>>>> >>> >>> >> > quoted-text-item → escaped-character<br>
>>>> >>> >>> >> > quoted-text-item → Any Unicode scalar value except ", \,<br>
>>>> >>> >>> >> > U+000A, or<br>
>>>> >>> >>> >> > U+000D<br>
>>>> >>> >>> >> > interpolated-string-literal → "interpolated-textopt"<br>
>>>> >>> >>> >> > interpolated-text → interpolated-text-item<br>
>>>> >>> >>> >> > interpolated-textopt<br>
>>>> >>> >>> >> > interpolated-text-item → \(expression) |<br>
>>>> >>> >>> >> > quoted-text-item<br>
>>>> >>> >>> >> > escaped-character → \0 | \\ | \t | \n | \r | \" | \'<br>
>>>> >>> >>> >> > escaped-character → \u{unicode-scalar-digits}<br>
>>>> >>> >>> >> > unicode-scalar-digits → Between one and eight hexadecimal<br>
>>>> >>> >>> >> > digit<br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> >><br>
>>>> >>> >>> >> >> On Wed, Dec 28, 2016 at 1:20 PM, Xiaodi Wu<br>
>>>> >>> >>> >> >> <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>><br>
>>>> >>> >>> >> >> wrote:<br>
>>>> >>> >>> >> >> > On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via<br>
>>>> >>> >>> >> >> > swift-evolution<br>
>>>> >>> >>> >> >> > <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> As an aide to learning I've been playing around with<br>
>>>> >>> >>> >> >> >> implementation<br>
>>>> >>> >>> >> >> >> of<br>
>>>> >>> >>> >> >> >> some of these concepts in the compiler and a few things<br>
>>>> >>> >>> >> >> >> popped up<br>
>>>> >>> >>> >> >> >> that<br>
>>>> >>> >>> >> >> >> I'm not happy with.<br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> First, regarding the way #fileLiteral works, it<br>
>>>> >>> >>> >> >> >> necessitates<br>
>>>> >>> >>> >> >> >> the<br>
>>>> >>> >>> >> >> >> addition of URL.init(fileReferenceLiteralR<wbr>esourceName:)<br>
>>>> >>> >>> >> >> >> which<br>
>>>> >>> >>> >> >> >> takes<br>
>>>> >>> >>> >> >> >> a<br>
>>>> >>> >>> >> >> >> string but does not return an optional value. Fine,<br>
>>>> >>> >>> >> >> >> except<br>
>>>> >>> >>> >> >> >> that I<br>
>>>> >>> >>> >> >> >> don't have to call #fileLiteral in my code to use that<br>
>>>> >>> >>> >> >> >> constructor,<br>
>>>> >>> >>> >> >> >> I<br>
>>>> >>> >>> >> >> >> can also use it directly. While I could get<br>
>>>> >>> >>> >> >> >> compile-time<br>
>>>> >>> >>> >> >> >> checking<br>
>>>> >>> >>> >> >> >> on<br>
>>>> >>> >>> >> >> >> the #fileLiteral, I can't on the direct constructor.<br>
>>>> >>> >>> >> >> >> Additionally, I<br>
>>>> >>> >>> >> >> >> could use the direct constructor with any String, not<br>
>>>> >>> >>> >> >> >> just<br>
>>>> >>> >>> >> >> >> literals.<br>
>>>> >>> >>> >> >> >> Internally that will call ```self =<br>
>>>> >>> >>> >> >> >> Bundle.main.url(forResource:<br>
>>>> >>> >>> >> >> >> name,<br>
>>>> >>> >>> >> >> >> withExtension: nil)!``` and crash at runtime if it's<br>
>>>> >>> >>> >> >> >> not<br>
>>>> >>> >>> >> >> >> found.<br>
>>>> >>> >>> >> >> >> Clearly we do not intend that init to be called<br>
>>>> >>> >>> >> >> >> directly,<br>
>>>> >>> >>> >> >> >> but<br>
>>>> >>> >>> >> >> >> that<br>
>>>> >>> >>> >> >> >> isn't clear to new Swift user Jude Doe, who discovers<br>
>>>> >>> >>> >> >> >> the<br>
>>>> >>> >>> >> >> >> API as<br>
>>>> >>> >>> >> >> >> xe<br>
>>>> >>> >>> >> >> >> autocompletes from Xcode.<br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> > That could be fixed with documentation. This API design<br>
>>>> >>> >>> >> >> > was<br>
>>>> >>> >>> >> >> > reviewed<br>
>>>> >>> >>> >> >> > and<br>
>>>> >>> >>> >> >> > approved as part of SE-0039:<br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> > <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md" rel="noreferrer" target="_blank">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0039-playgroundliterals.md</a><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> The second problem comes from String Interpolation.<br>
>>>> >>> >>> >> >> >> It's a<br>
>>>> >>> >>> >> >> >> basic<br>
>>>> >>> >>> >> >> >> problem I think with anything that extends the concept<br>
>>>> >>> >>> >> >> >> of<br>
>>>> >>> >>> >> >> >> the<br>
>>>> >>> >>> >> >> >> string_literal with additional requirements that need<br>
>>>> >>> >>> >> >> >> to be<br>
>>>> >>> >>> >> >> >> checked<br>
>>>> >>> >>> >> >> >> at<br>
>>>> >>> >>> >> >> >> compile-time. Right now I can put in something like<br>
>>>> >>> >>> >> >> >> ```#fileLiteral(resourceName: "\(myString)")```.<br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> > Can you? SE-0039 says that resourceName should be a<br>
>>>> >>> >>> >> >> > static-string-literal,<br>
>>>> >>> >>> >> >> > which (unless I'm mistaken) should forbid interpolation.<br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> While at one level it<br>
>>>> >>> >>> >> >> >> might seem nice to be able to construct this sort of<br>
>>>> >>> >>> >> >> >> thing,<br>
>>>> >>> >>> >> >> >> it's<br>
>>>> >>> >>> >> >> >> not<br>
>>>> >>> >>> >> >> >> at all nice from a validation perspective.<br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> I think this has to be solved at a higher level, in the<br>
>>>> >>> >>> >> >> >> Lexer,<br>
>>>> >>> >>> >> >> >> making<br>
>>>> >>> >>> >> >> >> a url literal a concept at that level, and<br>
>>>> >>> >>> >> >> >> fundamentally NOT<br>
>>>> >>> >>> >> >> >> a<br>
>>>> >>> >>> >> >> >> string<br>
>>>> >>> >>> >> >> >> literal underneath, even if they shared some similar<br>
>>>> >>> >>> >> >> >> constructs.<br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> The Lexer would be able to see #url("https://\(host)")<br>
>>>> >>> >>> >> >> >> and<br>
>>>> >>> >>> >> >> >> say<br>
>>>> >>> >>> >> >> >> "Invalid escape sequence in literal, \( is not<br>
>>>> >>> >>> >> >> >> understood as<br>
>>>> >>> >>> >> >> >> a<br>
>>>> >>> >>> >> >> >> url".<br>
>>>> >>> >>> >> >> >> In fact, the URL literal should probably not need ANY<br>
>>>> >>> >>> >> >> >> escape<br>
>>>> >>> >>> >> >> >> sequences<br>
>>>> >>> >>> >> >> >> or even the concept of escape sequences, since a<br>
>>>> >>> >>> >> >> >> double-quote is<br>
>>>> >>> >>> >> >> >> not<br>
>>>> >>> >>> >> >> >> a<br>
>>>> >>> >>> >> >> >> legal character in a URL.<br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> I definitely think we should take this opportunity to<br>
>>>> >>> >>> >> >> >> identify<br>
>>>> >>> >>> >> >> >> that<br>
>>>> >>> >>> >> >> >> we<br>
>>>> >>> >>> >> >> >> do NOT want to use string literal as it currently<br>
>>>> >>> >>> >> >> >> stands as<br>
>>>> >>> >>> >> >> >> a<br>
>>>> >>> >>> >> >> >> base<br>
>>>> >>> >>> >> >> >> construct for other literal types. Quite possibly<br>
>>>> >>> >>> >> >> >> there's<br>
>>>> >>> >>> >> >> >> another,<br>
>>>> >>> >>> >> >> >> more restricted concept that we can draw out of string<br>
>>>> >>> >>> >> >> >> literal<br>
>>>> >>> >>> >> >> >> that<br>
>>>> >>> >>> >> >> >> would make a good base construct, but certainly not a<br>
>>>> >>> >>> >> >> >> string<br>
>>>> >>> >>> >> >> >> literal<br>
>>>> >>> >>> >> >> >> with interpolation.<br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> On Wed, Dec 28, 2016 at 8:01 AM, Jonathan Hull via<br>
>>>> >>> >>> >> >> >> swift-evolution<br>
>>>> >>> >>> >> >> >> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > On Dec 27, 2016, at 11:46 AM, David Sweeris<br>
>>>> >>> >>> >> >> >> > <<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>><br>
>>>> >>> >>> >> >> >> > wrote:<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > On Dec 22, 2016, at 11:39 PM, Jonathan Hull<br>
>>>> >>> >>> >> >> >> > <<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>><br>
>>>> >>> >>> >> >> >> > wrote:<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > On Dec 20, 2016, at 12:29 PM, David Sweeris<br>
>>>> >>> >>> >> >> >> > <<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>><br>
>>>> >>> >>> >> >> >> > wrote:<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > On Dec 20, 2016, at 2:11 AM, Jonathan Hull via<br>
>>>> >>> >>> >> >> >> > swift-evolution<br>
>>>> >>> >>> >> >> >> > <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > Yes, I agree. I am excited to see what happens in<br>
>>>> >>> >>> >> >> >> > phase<br>
>>>> >>> >>> >> >> >> > 2.<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > What I am suggesting here is slightly different.<br>
>>>> >>> >>> >> >> >> > Basically<br>
>>>> >>> >>> >> >> >> > being<br>
>>>> >>> >>> >> >> >> > able<br>
>>>> >>> >>> >> >> >> > to<br>
>>>> >>> >>> >> >> >> > use<br>
>>>> >>> >>> >> >> >> > RegEx (with capture groups) as a shorthand for a type<br>
>>>> >>> >>> >> >> >> > composed<br>
>>>> >>> >>> >> >> >> > of<br>
>>>> >>> >>> >> >> >> > base<br>
>>>> >>> >>> >> >> >> > literals. For example: (StringLiteral,<br>
>>>> >>> >>> >> >> >> > [IntegerLiteral]).<br>
>>>> >>> >>> >> >> >> > Named<br>
>>>> >>> >>> >> >> >> > capture<br>
>>>> >>> >>> >> >> >> > groups could even map to a dictionary literal. I am<br>
>>>> >>> >>> >> >> >> > using<br>
>>>> >>> >>> >> >> >> > “RegEx<br>
>>>> >>> >>> >> >> >> > goes<br>
>>>> >>> >>> >> >> >> > Here”<br>
>>>> >>> >>> >> >> >> > to represent RegEx in the examples below, but<br>
>>>> >>> >>> >> >> >> > hopefully it<br>
>>>> >>> >>> >> >> >> > will<br>
>>>> >>> >>> >> >> >> > get<br>
>>>> >>> >>> >> >> >> > it’s<br>
>>>> >>> >>> >> >> >> > own<br>
>>>> >>> >>> >> >> >> > literal type in Xcode (Imagine that replacing it<br>
>>>> >>> >>> >> >> >> > here).<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > func foo( _ param: “RegExGoesHere”) {…} //Definition<br>
>>>> >>> >>> >> >> >> > uses<br>
>>>> >>> >>> >> >> >> > a<br>
>>>> >>> >>> >> >> >> > RegEx<br>
>>>> >>> >>> >> >> >> > where<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > type would normally be<br>
>>>> >>> >>> >> >> >> > foo(“my parseable string") //Calling with a string<br>
>>>> >>> >>> >> >> >> > literal<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > In this case, ‘param’ takes a string literal when<br>
>>>> >>> >>> >> >> >> > called<br>
>>>> >>> >>> >> >> >> > but<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > compiler<br>
>>>> >>> >>> >> >> >> > converts it to a tuple of literals based on the regEx<br>
>>>> >>> >>> >> >> >> > supplied<br>
>>>> >>> >>> >> >> >> > and<br>
>>>> >>> >>> >> >> >> > passes<br>
>>>> >>> >>> >> >> >> > that tuple the function. The type/structure of the<br>
>>>> >>> >>> >> >> >> > tuple<br>
>>>> >>> >>> >> >> >> > is<br>
>>>> >>> >>> >> >> >> > defined<br>
>>>> >>> >>> >> >> >> > by<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > capture groups in the RegEx<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > The parameter above would only allow string literals<br>
>>>> >>> >>> >> >> >> > to be<br>
>>>> >>> >>> >> >> >> > passed<br>
>>>> >>> >>> >> >> >> > in,<br>
>>>> >>> >>> >> >> >> > and<br>
>>>> >>> >>> >> >> >> > would give a compiler error if you tried to pass a<br>
>>>> >>> >>> >> >> >> > variable or<br>
>>>> >>> >>> >> >> >> > if<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > string<br>
>>>> >>> >>> >> >> >> > didn’t conform to the supplied RegEx. To allow<br>
>>>> >>> >>> >> >> >> > passing<br>
>>>> >>> >>> >> >> >> > String<br>
>>>> >>> >>> >> >> >> > variables<br>
>>>> >>> >>> >> >> >> > you<br>
>>>> >>> >>> >> >> >> > would have to add either ‘?’ or ‘!’ after the RegEx<br>
>>>> >>> >>> >> >> >> > definition<br>
>>>> >>> >>> >> >> >> > to<br>
>>>> >>> >>> >> >> >> > handle<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > case where the value doesn’t conform.<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > func foo( _ param: “RegExGoesHere”?) {…} //‘param' is<br>
>>>> >>> >>> >> >> >> > nil<br>
>>>> >>> >>> >> >> >> > if<br>
>>>> >>> >>> >> >> >> > RegEx<br>
>>>> >>> >>> >> >> >> > fails<br>
>>>> >>> >>> >> >> >> > foo(myStringVar) //Calling<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > func bar( _ param: “RegExGoesHere”!) {…} //fatal<br>
>>>> >>> >>> >> >> >> > error if<br>
>>>> >>> >>> >> >> >> > RegEx<br>
>>>> >>> >>> >> >> >> > fails<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > When a variable is passed, the RegEx is performed at<br>
>>>> >>> >>> >> >> >> > runtime<br>
>>>> >>> >>> >> >> >> > instead<br>
>>>> >>> >>> >> >> >> > of<br>
>>>> >>> >>> >> >> >> > compile time.<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > Once you have this, the syntax to add new literal<br>
>>>> >>> >>> >> >> >> > types/initializers<br>
>>>> >>> >>> >> >> >> > falls<br>
>>>> >>> >>> >> >> >> > out virtually for free.<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > Is “RegExGoesHere” where the regex pattern goes, or<br>
>>>> >>> >>> >> >> >> > where<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > string<br>
>>>> >>> >>> >> >> >> > you’re<br>
>>>> >>> >>> >> >> >> > trying to match goes? If it’s the latter, where does<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > pattern<br>
>>>> >>> >>> >> >> >> > go?<br>
>>>> >>> >>> >> >> >> > If<br>
>>>> >>> >>> >> >> >> > it’s<br>
>>>> >>> >>> >> >> >> > the former, where does the string you’re trying to<br>
>>>> >>> >>> >> >> >> > match<br>
>>>> >>> >>> >> >> >> > go?<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > “RegExGoesHere” is where the pattern goes (instead of<br>
>>>> >>> >>> >> >> >> > the<br>
>>>> >>> >>> >> >> >> > type).<br>
>>>> >>> >>> >> >> >> > The<br>
>>>> >>> >>> >> >> >> > string<br>
>>>> >>> >>> >> >> >> > you are trying to match gets passed in as the<br>
>>>> >>> >>> >> >> >> > parameter<br>
>>>> >>> >>> >> >> >> > (e.g.<br>
>>>> >>> >>> >> >> >> > “my<br>
>>>> >>> >>> >> >> >> > parseable<br>
>>>> >>> >>> >> >> >> > string”).<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > Ah, ok, I think I understand what you’re saying<br>
>>>> >>> >>> >> >> >> > now...<br>
>>>> >>> >>> >> >> >> > You’re<br>
>>>> >>> >>> >> >> >> > suggesting<br>
>>>> >>> >>> >> >> >> > that instead of defining a custom type that conforms<br>
>>>> >>> >>> >> >> >> > to<br>
>>>> >>> >>> >> >> >> > “RegExLiteral”<br>
>>>> >>> >>> >> >> >> > (or<br>
>>>> >>> >>> >> >> >> > some other mechanism) and using that as the<br>
>>>> >>> >>> >> >> >> > parameter’s<br>
>>>> >>> >>> >> >> >> > type,<br>
>>>> >>> >>> >> >> >> > you<br>
>>>> >>> >>> >> >> >> > put<br>
>>>> >>> >>> >> >> >> > your<br>
>>>> >>> >>> >> >> >> > regex pattern as the type directly?<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > Yes. It is admittedly an advanced feature, but I<br>
>>>> >>> >>> >> >> >> > think it<br>
>>>> >>> >>> >> >> >> > would<br>
>>>> >>> >>> >> >> >> > be a<br>
>>>> >>> >>> >> >> >> > useful<br>
>>>> >>> >>> >> >> >> > one.<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > Thanks,<br>
>>>> >>> >>> >> >> >> > Jon<br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > ______________________________<wbr>_________________<br>
>>>> >>> >>> >> >> >> > swift-evolution mailing list<br>
>>>> >>> >>> >> >> >> > <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
>>>> >>> >>> >> >> >> ><br>
>>>> >>> >>> >> >> >> ______________________________<wbr>_________________<br>
>>>> >>> >>> >> >> >> swift-evolution mailing list<br>
>>>> >>> >>> >> >> >> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>>>> >>> >>> >> >> >><br>
>>>> >>> >>> >> >> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ><br>
>>>> >>> >>> >> >> ______________________________<wbr>_________________<br>
>>>> >>> >>> >> >> swift-evolution mailing list<br>
>>>> >>> >>> >> >> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>>>> >>> >>> >> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> ><br>
>>>> >>> >>> >> ______________________________<wbr>_________________<br>
>>>> >>> >>> >> swift-evolution mailing list<br>
>>>> >>> >>> >> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>>>> >>> >>> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
>>>> >>> >>> ><br>
>>>> >>> >>> ><br>
>>>> >>> >><br>
>>>> >>> >><br>
>>>> >><br>
>>>> >><br>
>>>> ><br>
>>><br>
>>><br>
>><br>
><br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>