Re: [swift-evolution] URL Literals

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, w

Re: [swift-evolution] URL Literals

On Thu, Dec 29, 2016 at 3:18 PM, Micah Hainline 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,

Re: [swift-evolution] URL Literals

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

Re: [swift-evolution] URL Literals

> On Dec 28, 2016, at 11:36, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via swift-evolution >> 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

Re: [swift-evolution] URL Literals

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 r

Re: [swift-evolution] URL Literals

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 langua

Re: [swift-evolution] URL Literals

> 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

Re: [swift-evolution] URL Literals

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 w

Re: [swift-evolution] URL Literals

As an aide to learning I've been playing around with implementation of some of these concepts in the compiler and a few things popped up that I'm not happy with. First, regarding the way #fileLiteral works, it necessitates the addition of URL.init(fileReferenceLiteralResourceName:) which takes a s

Re: [swift-evolution] URL Literals

> On Dec 27, 2016, at 11:46 AM, David Sweeris wrote: > >> >> On Dec 22, 2016, at 11:39 PM, Jonathan Hull > > wrote: >> >> >>> On Dec 20, 2016, at 12:29 PM, David Sweeris >> > wrote: >>> On Dec 20, 2016, at 2:11 AM, Jonathan Hull v

Re: [swift-evolution] URL Literals

> On Dec 22, 2016, at 11:39 PM, Jonathan Hull wrote: > > >> On Dec 20, 2016, at 12:29 PM, David Sweeris > > wrote: >> >>> >>> On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Yes, I agree. I am

Re: [swift-evolution] URL Literals

> On Dec 20, 2016, at 12:29 PM, David Sweeris wrote: > >> >> On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution >> mailto: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. Ba

Re: [swift-evolution] URL Literals

We're nowhere close to bikeshedding the name yet; people are calling it constexpr to mean that the idea is something along the lines of C++'s constexpr, as opposed to C++'s const. Mentally substitute whatever word you want at the moment. On Fri, Dec 23, 2016 at 02:15 Georgios Moschovitis < george

Re: [swift-evolution] URL Literals

> As a bonus (IMHO, anyway) adding `@constexpr` would lay the groundwork for > adding `@pure` later on, both in Could that be just `@const` (since that keyword is not reserved yet)? Or something else? It bugs be that the `constexpr` keyword is hard to pronounce (and lacks a separator between

Re: [swift-evolution] URL Literals

> On Dec 20, 2016, at 8:28 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull > > wrote: >> >> Yes, I agree. I am excited to see what happens in phase 2. >> >> What I am suggesting here is slightly different. Basically being

Re: [swift-evolution] URL Literals

Oops… typo... > On Dec 20, 2016, at 12:29 PM, David Sweeris via swift-evolution > wrote: > > [...] According to “Daveo” (not me) on stackoverflow > (http://stackoverflow.com/questions/3809401/what-is-a-good-regular-expression-to-match-a-url > >

Re: [swift-evolution] URL Literals

> On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution > 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

Re: [swift-evolution] URL Literals

On Tue, Dec 20, 2016 at 4:11 AM, Jonathan Hull 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: (S

Re: [swift-evolution] URL Literals

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 ev

Re: [swift-evolution] URL Literals

Regex is another thing that appears on many platforms and has a standard way to express it. -- E > On Dec 19, 2016, at 5:51 PM, Jonathan Hull wrote: > > +1 to Erica’s literal extensions (and Xiaodi’s idea of showing Favicons in > Xcode where possible) > > Perhaps the easiest way to allow arb

Re: [swift-evolution] URL Literals

Mixfix operators were a possibility sketched out in a recent proposal draft on operators by Jonathan Shapiro. That would enable custom syntax like you show here. Not sure if a revision of that draft is still in the works. On Mon, Dec 19, 2016 at 22:37 Daniel Leping via swift-evolution < swift-evo

Re: [swift-evolution] URL Literals

I believe regex was one of the topics that the core team proposed was a possibility for phase 2. I too am eager to hear what they have in mind. On Mon, Dec 19, 2016 at 23:02 Erica Sadun wrote: > Regex is another thing that appears on many platforms and has a standard > way to express it. > > -- E

Re: [swift-evolution] URL Literals

I was thinking about a possibility to extend the language itself with custom literals. It should cover quite some stuff including URL, Regex, etc. Just add an extended operator-ish syntax. Can be done with regular expressions or similar. //RegexLiteralDefinition literal /(.*)/(.*)/ (regex:String,

Re: [swift-evolution] URL Literals

+1 to Erica’s literal extensions (and Xiaodi’s idea of showing Favicons in Xcode where possible) Perhaps the easiest way to allow arbitrary literal extensions beyond those would be, in phase 2 when we add RegEx to the language, to take a RegEx defining the custom literal and have the compiler o

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:55 AM, David Sweeris via swift-evolution > wrote: > > >> On Dec 19, 2016, at 11:48 AM, Xiaodi Wu > > wrote: >> >> On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On De

Re: [swift-evolution] URL Literals

The behavior is not altogether clear to me either. Since XCode does show a preview of images, it's fair to think that there's some sort of compile-time validation going on. I would not be opposed to image and file literals changing their behavior so that when a user drags a file into the IDE the f

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:48 AM, Xiaodi Wu wrote: > > On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:44 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution < > swift-evolution@s

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:36 AM, David Sweeris via swift-evolution > wrote: > > >> On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> ```swift >> let x = #imageLiteral(resourceName:"nothere.jpg") >> print(x) >> ``` >> >> This comp

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:40 PM, Xiaodi Wu wrote: > On Mon, Dec 19, 2016 at 1:18 PM, Tony Allevato > wrote: > >> +1 to the sentiment in your last paragraph. >> >> In general, I'm not a very big fan of the #foo(...) syntax for literals >> and I think using that as the starting point for discussio

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:18 PM, Tony Allevato wrote: > +1 to the sentiment in your last paragraph. > > In general, I'm not a very big fan of the #foo(...) syntax for literals > and I think using that as the starting point for discussion biases us > towards those when more general and powerful al

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 11:21 AM, Erica Sadun via swift-evolution > wrote: > > ```swift > let x = #imageLiteral(resourceName:"nothere.jpg") > print(x) > ``` > > This compiles. It crashes at runtime. I don't see why URLs should be any > different. > > — E They shouldn’t be. The print function

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 12:18 PM, Tony Allevato via swift-evolution > wrote: > > +1 to the sentiment in your last paragraph. > > In general, I'm not a very big fan of the #foo(...) syntax for literals and I > think using that as the starting point for discussion biases us towards those > when

Re: [swift-evolution] URL Literals

```swift let x = #imageLiteral(resourceName:"nothere.jpg") print(x) ``` This compiles. It crashes at runtime. I don't see why URLs should be any different. -- E > On Dec 19, 2016, at 11:53 AM, David Sweeris via swift-evolution > wrote: > >> >> On Dec 19, 2016, at 1:26 AM, Xiaodi Wu >

Re: [swift-evolution] URL Literals

+1 to the sentiment in your last paragraph. In general, I'm not a very big fan of the #foo(...) syntax for literals and I think using that as the starting point for discussion biases us towards those when more general and powerful alternatives could exist. That syntax exists for Playground support

Re: [swift-evolution] URL Literals

> On Dec 19, 2016, at 1:26 AM, Xiaodi Wu wrote: > > URLs are unlikely to be something that can be validated by regex. See, for > instance, this discussion: > >. The full spec is > here

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 8:47 AM, Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: > Regarding validation of resources being reachable or existing, I think we > should take that right off the table, for all types of URLs. Firstly, > because it could be very error prone. Consid

[swift-evolution] URL Literals

I would like to be able to create a URL literal that is compile-time checked for correct format. This would help avoid code like this: let url = URL(string: "https://example.com";)! The cleanest way I can think of doing that would be to introduce a new macro structure similar to #selector, th

Re: [swift-evolution] URL Literals

Regarding validation of resources being reachable or existing, I think we should take that right off the table, for all types of URLs. Firstly, because it could be very error prone. Consider even the basic case of the deployment environment having access to the resource while the build environment

Re: [swift-evolution] URL Literals

On Mon, Dec 19, 2016 at 1:55 AM, Benjamin Spratling wrote: > Howdy, > I'm definitely on the "no force unwrapping bandwagon". And I also see > a huge difference in force-unwrapping a value derived from a literal, which > can be unit tested, and force-unwrapping a value determined at run time,

Re: [swift-evolution] URL Literals

URLs are unlikely to be something that can be validated by regex. See, for instance, this discussion: < https://webkit.org/blog/7086/url-parsing-in-webkit/>. The full spec is here: . If Swift were to implement parsing of URLs at the level of the compiler or core library

Re: [swift-evolution] URL Literals

Howdy, Yes, I was also intrigued by the “Regex” validation mentioned in another post. It could offer a convenient way to get some literals support in without the headaches associated with the constexpr C++ approach. I’m curious, though, how many types can we image in can be valid

Re: [swift-evolution] URL Literals

I like where this is going! +1 Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 19 Dec 2016, at 08:41, David Sweeris via swift-evolution > wrote: > > >> On Dec 17, 2016, at 1:12 PM, Micah

Re: [swift-evolution] URL Literals

Howdy, I'm definitely on the "no force unwrapping bandwagon". And I also see a huge difference in force-unwrapping a value derived from a literal, which can be unit tested, and force-unwrapping a value determined at run time, which might fail validation. That's where I draw the line. I ha

Re: [swift-evolution] URL Literals

> On Dec 17, 2016, at 1:12 PM, Micah Hainline via swift-evolution > wrote: > > I'd love a fleshed out elegant example for URL that shows what a complete > implementation of that special init method would look like. Sorry this took so long… the weekend kinda got away from me. Anyway, I was t

Re: [swift-evolution] URL Literals

I personally would like something that lived outside the standard library and outside the immediate compiler. I don't think the color, file, and image literals that exist really should be part of core Swift. But I also don't think they should be Foundation either. I also would prefer something e

Re: [swift-evolution] URL Literals

With the passage of time, I continue to believe that literals in Swift are fundamentally valuable because they can, er, literally (or immediately/WYSIWYG-ly?) show in code something that must otherwise be interpreted by the human reader and then visualized in the mind's eye, and they allow users to

Re: [swift-evolution] URL Literals

Earlier in this thread, I pasted in a draft I discussed on-list (from July 10) about extending literals to include other "universal" typeless concepts including fonts, dates, points, etc but I should have spent a moment discussing why I had dropped that link. -- E p.s. For those that missed it

Re: [swift-evolution] URL Literals

That's a fair point. I suppose we could have, in the same way as file literals, ``` #urlLiteral(resourceName: "http://example.com";) ``` which in an IDE would be automatically generated when someone drops a link and might be rendered as a hyperlink, blue underline and all. On Sun, Dec 18, 2016

Re: [swift-evolution] URL Literals

I'd prefer to see a literal URL than a Foundation URL that is string-initializable. I don't see a URL literal as being in any way necessarily tightly coupled with a Foundation URL type. The point of a literal is that it is inherently typeless and checked at compile time. A color literal dependin

Re: [swift-evolution] URL Literals

With respect to URL specifically, that it's a Foundation type may change the timeline as well. Various improvements to the Foundation API (and URL in particular) have been proposed here, but if I remember correctly, the stated goal was first to have a complete Swift version of Foundation, preservin

Re: [swift-evolution] URL Literals

Probably worth pointing out that this topic seems entirely additive. Which means it would be at least a phase 2 proposal, if not later. > On Dec 17, 2016, at 4:44 PM, Micah Hainline via swift-evolution > wrote: > > Yes, everyone who has what they feel like is a solid workable solution should

Re: [swift-evolution] URL Literals

Yes, everyone who has what they feel like is a solid workable solution should write it up for URL and we can compare and pick holes in them all until we get something really solid. > On Dec 17, 2016, at 3:27 PM, David Sweeris wrote: > > > > Sent from my iPhone > >> On Dec 17, 2016, at 13:20

Re: [swift-evolution] URL Literals

Sent from my iPhone > On Dec 17, 2016, at 13:20, David Sweeris wrote: > > > > Sent from my iPhone > >> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution >> wrote: >> >> I'd love a fleshed out elegant example for URL that shows what a complete >> implementation of that specia

Re: [swift-evolution] URL Literals

Sent from my iPhone > On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution > wrote: > > I'd love a fleshed out elegant example for URL that shows what a complete > implementation of that special init method would look like. I can't do it now, but I'll try post one before tomorrow t

Re: [swift-evolution] URL Literals

> On Dec 17, 2016, at 11:15, Anton Zhilin wrote: > > I was in the process of writing something along those lines :) > > But I would prefer this attribute to be added implicitly by the compiler. > Then, if we want to validate that some function is statically computable, we > add @pure to the fu

Re: [swift-evolution] URL Literals

So here are some thoughts. I like the idea of an annotation for compile-time validation, though I haven't given up on simple #url yet either. For the people interested in @pure for its implications for functional programming, I'm questioning if that concept sufficiently limits the problem when y

Re: [swift-evolution] URL Literals

I was in the process of writing something along those lines :) But I would prefer this attribute to be added implicitly by the compiler. Then, if we want to *validate* that some function is statically computable, we add @pure to the function. If we want to *require* that some variable is computed

Re: [swift-evolution] URL Literals

Sent from my iPhone > On Dec 17, 2016, at 09:47, Xiaodi Wu via swift-evolution > wrote: > > I was thinking of even more explicitly venturing into `constexpr` territory > by allowing particular initializers and functions to be marked as > `@constantExpression` (or however you want to call it

Re: [swift-evolution] URL Literals

I suppose if compile time validation is desired I guess we can do something similar to @ibdesignables. Except instead of live rendering UIViews we would render the url Marking a URL like this @urlvalidation("a URL string") Would make it fire a compiletime URL request and give a warning if it was

Re: [swift-evolution] URL Literals

It would be a good idea for literals of different types to be easily recognizable in the source by human readers and extractable from the source by tools. I'm sure everyone agrees that it's annoying/risky when you can't even distinguish localizable strings (user messages) from non-localizable strin

Re: [swift-evolution] URL Literals

+1. What Tony outlined is exactly in the realm of what I had in mind. I was thinking of even more explicitly venturing into `constexpr` territory by allowing particular initializers and functions to be marked as `@constantExpression` (or however you want to call it) when they use a restricted subs

[swift-evolution] URL Literals

I like the David Sweeris idea best. The syntax is cleaner and the type URL "knows what to do with itself". let url: URL = "https://example.com"; I have strong reservations about hard-coded URLs as an SDLC 🚂 wreck waiting to happen, but the world of mid-day build and deploy might mitigate this,

Re: [swift-evolution] URL Literals

+1. Tony’s static evaluation idea also crossed my mind when reading this thread. > On Dec 17, 2016, at 10:52 AM, Tony Allevato via swift-evolution > wrote: > > If folks want to go down this path, it: > > * shouldn't require compiler magic > * shouldn't be restricted to specific types > * sho

Re: [swift-evolution] URL Literals

If folks want to go down this path, it: * shouldn't require compiler magic * shouldn't be restricted to specific types * should be something that anyone can take advantage of in types that they write. The most general approach that jumps immediately to my mind is letting users write code in a res

Re: [swift-evolution] URL Literals

Sent from my iPhone > On Dec 16, 2016, at 12:46, Micah Hainline via swift-evolution > wrote: > > I would like to be able to create a URL literal that is compile-time > checked for correct format. This would help avoid code like this: > >let url: URL = URL(string: "https://example.com";)!

Re: [swift-evolution] URL Literals

Do you have a treatment in mind? Perhaps the compiler recognizes types/initializers it can check at compile time (how?). Then it could synthesize non-failable initializers. Or would the author write a non-failable init with some type of annotation that the parameters must be literals? (Here I

Re: [swift-evolution] URL Literals

Actually, a syntax similar to the one I described was considered for selectors; it was rejected in favor of #selector because something like Selector(Foo.bar) is apparently more difficult to implement, and the core team said that "on balance, we didn't want to introduce type system complexities for

Re: [swift-evolution] URL Literals

Absolutely. Good breakdown of the issues. I will draw a parallel with #selector though for past precedent. It wouldn't have been much different to just use the string-based Selector creation instead of creating a new language feature and just validate string literals in that context to verify th

Re: [swift-evolution] URL Literals

On Fri, Dec 16, 2016 at 8:00 PM, Micah Hainline wrote: > We'll have to agree to disagree about the value of getting rid of the > force-unwrap. > I suppose we may have to. But I hope to have convinced you that what you're really getting at here are two issues that can be separated. The two are:

Re: [swift-evolution] URL Literals

We'll have to agree to disagree about the value of getting rid of the force-unwrap. > On Dec 16, 2016, at 7:54 PM, Xiaodi Wu wrote: > >> On Fri, Dec 16, 2016 at 7:44 PM, Micah Hainline >> wrote: >> Noted, but again while force-unwrapping it is the best we have, compile-time >> checking would

Re: [swift-evolution] URL Literals

On Fri, Dec 16, 2016 at 7:44 PM, Micah Hainline wrote: > Noted, but again while force-unwrapping it is the best we have, > compile-time checking would be even better. > Sure, I'm certainly not opposed to flagging more errors at compile time. But it's possible to do that without adding new syntax

Re: [swift-evolution] URL Literals

Noted, but again while force-unwrapping it is the best we have, compile-time checking would be even better. > On Dec 16, 2016, at 7:30 PM, Xiaodi Wu wrote: > >> On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline >> wrote: >> It's not super strong, but it's as strong as the URL type itself. >>

Re: [swift-evolution] URL Literals

On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline wrote: > It's not super strong, but it's as strong as the URL type itself. > > Even if I do checking related to the resource being unavailable, I also > have to do checking to account for the possibility of a nil URL. The two > checks aren't closely

Re: [swift-evolution] URL Literals

I have to agree with your line of thinking, Micah. We've been in the exact same position when it comes to teaching beginners to avoid force unwrapping except URLs. +1 on this from me! Mark > On Dec 16, 2016, at 19:01, Micah Hainline via swift-evolution > wrote: > > It's not super strong, bu

Re: [swift-evolution] URL Literals

It's not super strong, but it's as strong as the URL type itself. Even if I do checking related to the resource being unavailable, I also have to do checking to account for the possibility of a nil URL. The two checks aren't closely related. It does help to have one of them accounted for by the

Re: [swift-evolution] URL Literals

On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: > True, but it's not at all about brevity, it's about type-safety and > getting compile-time checking rather than runtime checking of the validity > of the URL structure. > While I understand t

Re: [swift-evolution] URL Literals

I'm not sure I fully understand the value proposition of having all those different kinds of literals, but one piece of feedback I have on that is the previously established format for the # notation should be #camelCase rather than #dot.separated. > On Dec 16, 2016, at 5:41 PM, Erica Sadun wr

Re: [swift-evolution] URL Literals

True, but it's not at all about brevity, it's about type-safety and getting compile-time checking rather than runtime checking of the validity of the URL structure. > On Dec 16, 2016, at 5:50 PM, Derrick Ho wrote: > > let url = URL(string: "https://example.com";)! > > let url = #url("https://

Re: [swift-evolution] URL Literals

let url = URL(string: "https://example.com";)! let url = #url("https://example.com";) Are not that different in length. It really isn't saving you much. I suppose you can try overloading an operator to get something to the effect you want. On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift

Re: [swift-evolution] URL Literals

Take a peek at this: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c --E > On Dec 16, 2016, at 2:58 PM, Micah Hainline via swift-evolution > wrote: > > Charles, > > There's already something like that for file U

Re: [swift-evolution] URL Literals

Exactly! It's not an earth-shattering pain, but it would be nice to have clean type safety there. > On Dec 16, 2016, at 4:01 PM, Charlie Monroe wrote: > > >>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution >>> wrote: >>> >>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via

Re: [swift-evolution] URL Literals

Charles, There's already something like that for file URLs in a playground, though I'm not sure about compile-time checking or how that might work outside of playgrounds. https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/60.html Of course, my proposal would work fine for

Re: [swift-evolution] URL Literals

> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution > wrote: > >> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution >> wrote: >> >> I would like to be able to create a URL literal that is compile-time >> checked for correct format. This would help avoid code like

Re: [swift-evolution] URL Literals

> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution > wrote: > > I would like to be able to create a URL literal that is compile-time > checked for correct format. This would help avoid code like this: > >let url: URL = URL(string: "https://example.com";)! > > The cleanest wa

[swift-evolution] URL Literals

I would like to be able to create a URL literal that is compile-time checked for correct format. This would help avoid code like this: let url: URL = URL(string: "https://example.com";)! The cleanest way I can think of doing that would be to introduce a new macro structure similar to #selecto