# URL Literals **URL:** \ **Category:** Discussion\ **Created:** [December 16, 2016, 8:46pm UTC](https://forums.swift.org/t/url-literals/4728 "2016-12-16T20:46:34Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Benjamin\_Spratling](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benjamin_spratling/32/2488_2.png) [@Benjamin\_Spratling](https://forums.swift.org/u/Benjamin_Spratling)\ **Post date:** [December 19, 2016, 7:55am UTC](https://forums.swift.org/t/url-literals/4728/21 "2016-12-19T07:55:11Z")
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 have seen some good developers "think" they "know" the value can't be nil, and they were just wrong. But when we can specifically run a unit test with 0 inputs on the value, then falsification of nullability is easy. -Ben > **···** > > Sent from my iPhone. > > > On Dec 16, 2016, at 7:30 PM, Xiaodi Wu via swift-evolution \ 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. > > > > > > 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. > > > > When you use a URL, what would you do differently when a resource is unavailable versus when the URL is malformed, especially if you're hardcoding the URL? > > > > > It does help to have one of them accounted for by the compiler if possible. > > > > > > I'm trying to teach some less experienced developers to think of force-unwrapping as a code smell, > > > > There have been a few people who have said a similar thing on the list, but I don't think this is the official line about force-unwrapping. Force unwrapping is an explicitly supported part of the language that has its uses. If you \*know\* at the time of writing that a failable initializer should never fail, then `!` is an expressive, clear, concise, entirely appropriate, and I would even say the \*best\* way of indicating that to your reader. > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` is one example of this usage, but not at all the only one. I have previously written, for example, `"L".cString(using: .utf8)!`. This is also no code smell, as what I'm doing is stating my absolute confidence (and indicating that confidence to the reader) that the letter L can be encoded using UTF-8. > > > > > but it's not the best to have to say "except for URLs". I realize the utility of the proposed change is reasonably small, but I also think it's purely additive and consistent with the rest of the language. 🙂 > > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > > > > > > On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution \ 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 that what you're after is compile-time checking of validity, I'm not convinced that it is materially useful. I also don't see how it's contributing to type safety. Perhaps you could illuminate what use case has persuaded you of these things? Here's my thinking: > > > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of a URL, it's a mistake that results in a plausible but unintended URL and a compile-time check for validity will not help at all. To guard against such an error, I need to write tests anyway and could never depend on the compiler. In fact, I'd imagine that doing anything useful with a URL--even a hardcoded one--will require some thought as to how to deal with error handling at runtime. How is it helpful to have only the lowest bar (a technically valid URL format) ensured at compile time instead of runtime? By contrast, Swift selectors help to guarantee that any particular function I'm referring to actually exists; when that is ensured at compile time, I know it will be the case at runtime. There's no corresponding guarantee by having a compile-time check for URL validity that the resource pointed to will actually exist. That the nonexistent resource was denoted by a string that had the correct format of a URL is cold comfort, no? > > > > > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > > > > > > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > > > > > > > > > let url = #url("[https://example.com](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-evolution \ wrote: > > > > > > > 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 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](https://example.com)")! > > > > > > > \>\>\> > > > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a new > > > > > > > \>\>\> macro structure similar to #selector, though I'm open to other ideas. > > > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > > > \>\>\> problems. That would look like this: > > > > > > > \>\>\> > > > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > > > > \>\>\> > > > > > > > \>\>\> What does everyone think of that idea? > > > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > \>\>\> swift-evolution mailing list > > > > > > > \>\>\> swift-evolution@swift.org > > > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > \>\> > > > > > > > \>\> > > > > > > > \>\> I’d like to see something like that for file path URLs. For something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > > > \>\> > > > > > > > \>\> Charles > > > > > > > \> > > > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the incredible pain is that even compile-time URLs to your own website are nullable URL? and you need to force-unwrap them. > > > > > > > \> > > > > > > > \>\> > > > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > \>\> swift-evolution mailing list > > > > > > > \>\> swift-evolution@swift.org > > > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > \> > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Step](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/step/32/305_2.png) [@Step](https://forums.swift.org/u/Step)\ **Post date:** [December 17, 2016, 1:57pm UTC](https://forums.swift.org/t/url-literals/4728/22 "2016-12-17T13:57:27Z")
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 am using literals to mean values that are understood by the compiler.) - Step > **···** > > > On Dec 16, 2016, at 9:46 PM, Xiaodi Wu via swift-evolution \ wrote: > > > > 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 relatively rare ObjC interop features". > > > > However, I would think that the general issue of compiler help to indicate when certain initializers are guaranteed to fail is the opposite of a "relatively rare interop feature" and deserves perhaps a more holistic treatment rather than a selector-like quick-fix for URLs only. > > > > > On Fri, Dec 16, 2016 at 20:33 Micah Hainline \ wrote: > > > 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 they're okay in much the same way you describe here. There was value in breaking that out differently though, partly because it makes very clear what will and what will not be validated. > > > > > > I don't think force-unwrapping is exactly an anti pattern, but it is one of the less desirable patterns, and I do think it should be avoided where cleanly possible. > > > > > > > On Dec 16, 2016, at 8:14 PM, Xiaodi Wu \ wrote: > > > > > > > > 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: > > > > > > > > 1. The developer experience of using failable initializers invoked with hardcoded arguments is sub-par. For URL, or for any other type where success or failure of initialization is determined entirely by the arguments passed in, it would be nice to have the compiler tell you \_at compile time\_ if the hardcoded arguments are guaranteed to cause the initializer to return nil. I think this is quite an insightful point. > > > > > > > > 2. You do not like working with force unwrapping. While certainly entitled to that opinion, I do not think this opinion alone (since it is separable from (1)) can justify additions or subtractions to the language. Either force unwrapping is a legitimate part of the language--that is, the community that designs Swift can agree on specific patterns where its use is considered best practice--or it is an anti-pattern that should be deprecated and eventually removed. It cannot be a lingering yet fully supported first-class anti-pattern that we design standard and core library APIs actively to avoid. > > > > > > > > > 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 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 to the language, which (just MHO) is rarely the best solution when a good alternative exists. > > > > > > > > > > Here, for instance, one could add compiler magic that warns at compile time that `URL(string: "notavalidurl")!` is guaranteed to fail. That could be a diagnostics/QoI improvement that almost certainly wouldn't require going through the evolution process. > > > > > > > > > > What I was trying to point out is that I agree with Derrick that the \_spelling\_ `URL(string: "[https://example.com/"\](https://example.com/"%5C))!` is perfectly fine and not in need of improvement, and that I disagree strongly that force unwrapping is problematic as a matter of style. > > > > > > > > > > > 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. > > > > > > > > > > > > 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. > > > > > > > > > > > > When you use a URL, what would you do differently when a resource is unavailable versus when the URL is malformed, especially if you're hardcoding the URL? > > > > > > > > > > > > It does help to have one of them accounted for by the compiler if possible. > > > > > > > > > > > > I'm trying to teach some less experienced developers to think of force-unwrapping as a code smell, > > > > > > > > > > > > There have been a few people who have said a similar thing on the list, but I don't think this is the official line about force-unwrapping. Force unwrapping is an explicitly supported part of the language that has its uses. If you \*know\* at the time of writing that a failable initializer should never fail, then `!` is an expressive, clear, concise, entirely appropriate, and I would even say the \*best\* way of indicating that to your reader. > > > > > > > > > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` is one example of this usage, but not at all the only one. I have previously written, for example, `"L".cString(using: .utf8)!`. This is also no code smell, as what I'm doing is stating my absolute confidence (and indicating that confidence to the reader) that the letter L can be encoded using UTF-8. > > > > > > > > > > > > but it's not the best to have to say "except for URLs". I realize the utility of the proposed change is reasonably small, but I also think it's purely additive and consistent with the rest of the language. 🙂 > > > > > > > > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > > > > > > > > > > > On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution \ 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 that what you're after is compile-time checking of validity, I'm not convinced that it is materially useful. I also don't see how it's contributing to type safety. Perhaps you could illuminate what use case has persuaded you of these things? Here's my thinking: > > > > > > > > > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of a URL, it's a mistake that results in a plausible but unintended URL and a compile-time check for validity will not help at all. To guard against such an error, I need to write tests anyway and could never depend on the compiler. In fact, I'd imagine that doing anything useful with a URL--even a hardcoded one--will require some thought as to how to deal with error handling at runtime. How is it helpful to have only the lowest bar (a technically valid URL format) ensured at compile time instead of runtime? By contrast, Swift selectors help to guarantee that any particular function I'm referring to actually exists; when that is ensured at compile time, I know it will be the case at runtime. There's no corresponding guarantee by having a compile-time check for URL validity that the resource pointed to will actually exist. That the nonexistent resource was denoted by a string that had the correct format of a URL is cold comfort, no? > > > > > > > > > > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > > > > > > > > > > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > > > > > > > > > > > > > let url = #url("[https://example.com](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-evolution \ wrote: > > > > > > > > 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 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](https://example.com)")! > > > > > > > > \>\>\> > > > > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a new > > > > > > > > \>\>\> macro structure similar to #selector, though I'm open to other ideas. > > > > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > > > > \>\>\> problems. That would look like this: > > > > > > > > \>\>\> > > > > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > > > > > \>\>\> > > > > > > > > \>\>\> What does everyone think of that idea? > > > > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > \>\>\> swift-evolution mailing list > > > > > > > > \>\>\> swift-evolution@swift.org > > > > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \>\> > > > > > > > > \>\> > > > > > > > > \>\> I’d like to see something like that for file path URLs. For something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > > > > \>\> > > > > > > > > \>\> Charles > > > > > > > > \> > > > > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the incredible pain is that even compile-time URLs to your own website are nullable URL? and you need to force-unwrap them. > > > > > > > > \> > > > > > > > > \>\> > > > > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > \>\> swift-evolution mailing list > > > > > > > > \>\> swift-evolution@swift.org > > > > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \> > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > swift-evolution mailing list > > > > > > > > swift-evolution@swift.org > > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [December 19, 2016, 9:39am UTC](https://forums.swift.org/t/url-literals/4728/23 "2016-12-19T09:39:42Z")
> 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 have seen some good developers "think" they "know" the value can't be > nil, and they were just wrong. Well, sure, but the fault originated with the good developer being wrong, not with `!`. All I'm saying is, there are legitimate use cases where one intends to have this behavior: ```swift guard let foo = bar else { fatalError() // Bye. } ``` In those cases, it is perfectly legitimate to write: ```swift let foo = bar! ``` But when we can specifically run a unit test with 0 inputs on the value, > **···** > > On Mon, Dec 19, 2016 at 1:55 AM, Benjamin Spratling \ wrote: > > > then falsification of nullability is easy. > > > > -Ben > > > > Sent from my iPhone. > > > > On Dec 16, 2016, at 7:30 PM, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> 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. > > > > > > 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. > > > > When you use a URL, what would you do differently when a resource is > > unavailable versus when the URL is malformed, especially if you're > > hardcoding the URL? > > > > It does help to have one of them accounted for by the compiler if possible. > > > > > I'm trying to teach some less experienced developers to think of > > > force-unwrapping as a code smell, > > > > There have been a few people who have said a similar thing on the list, > > but I don't think this is the official line about force-unwrapping. Force > > unwrapping is an explicitly supported part of the language that has its > > uses. If you \*know\* at the time of writing that a failable initializer > > should never fail, then `!` is an expressive, clear, concise, entirely > > appropriate, and I would even say the \*best\* way of indicating that to your > > reader. > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` > > is one example of this usage, but not at all the only one. I have > > previously written, for example, `"L".cString(using: .utf8)!`. This is also > > no code smell, as what I'm doing is stating my absolute confidence (and > > indicating that confidence to the reader) that the letter L can be encoded > > using UTF-8. > > > > but it's not the best to have to say "except for URLs". I realize the > > > > > utility of the proposed change is reasonably small, but I also think it's > > > purely additive and consistent with the rest of the language. 🙂 > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > > > 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 that what you're after is compile-time checking of > > > validity, I'm not convinced that it is materially useful. I also don't see > > > how it's contributing to type safety. Perhaps you could illuminate what use > > > case has persuaded you of these things? Here's my thinking: > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of a > > > URL, it's a mistake that results in a plausible but unintended URL and a > > > compile-time check for validity will not help at all. To guard against such > > > an error, I need to write tests anyway and could never depend on the > > > compiler. In fact, I'd imagine that doing anything useful with a URL--even > > > a hardcoded one--will require some thought as to how to deal with error > > > handling at runtime. How is it helpful to have only the lowest bar (a > > > technically valid URL format) ensured at compile time instead of runtime? > > > By contrast, Swift selectors help to guarantee that any particular function > > > I'm referring to actually exists; when that is ensured at compile time, I > > > know it will be the case at runtime. There's no corresponding guarantee by > > > having a compile-time check for URL validity that the resource pointed to > > > will actually exist. That the nonexistent resource was denoted by a string > > > that had the correct format of a URL is cold comfort, no? > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > > > > > let url = #url("[https://example.com](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-evolution \< \>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > > 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 \< \>\>\>\> charlie@charliemonroe.net\> wrote: > > > > > \> > > > > > \> > > > > > \>\>\> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution \< \>\>\>\> swift-evolution@swift.org\> wrote: > > > > > \>\>\> > > > > > \>\>\> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution \< \>\>\>\> swift-evolution@swift.org\> 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](https://example.com)")! > > > > > \>\>\> > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a > > > > > new > > > > > \>\>\> macro structure similar to #selector, though I'm open to other > > > > > ideas. > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > \>\>\> problems. That would look like this: > > > > > \>\>\> > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > > \>\>\> > > > > > \>\>\> What does everyone think of that idea? > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > \>\>\> swift-evolution mailing list > > > > > \>\>\> swift-evolution@swift.org > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > \>\> > > > > > \>\> > > > > > \>\> I’d like to see something like that for file path URLs. For > > > > > something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > \>\> > > > > > \>\> Charles > > > > > \> > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the > > > > > incredible pain is that even compile-time URLs to your own website are > > > > > nullable URL? and you need to force-unwrap them. > > > > > \> > > > > > \>\> > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > \>\> swift-evolution mailing list > > > > > \>\> swift-evolution@swift.org > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > \> > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Tony\_Allevato](https://avatars.discourse-cdn.com/v4/letter/t/f1d935/32.png) [@Tony\_Allevato](https://forums.swift.org/u/Tony_Allevato)\ **Post date:** [December 17, 2016, 4:52pm UTC](https://forums.swift.org/t/url-literals/4728/24 "2016-12-17T16:52:46Z")
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 restricted subset of the language that would be evaluated at statically at compile time. It's getting into C++ "constexpr" territory, but I wouldn't want to settle for something that tightly couples special behavior to just a few types. Quick back of the napkin sketch, I haven't thought too much about syntax details yet: struct URL: ExpressibleByStringLiteral {   // the #, or something similar, indicates this   // is compile-time evaluation   #init?(\_ stringLiteral: StaticString) {     // validate the string. We'd be able to use     // loops and access individual characters     // in the static string... regexes would be     // trickier.     if valid {       // if we get here, everything we did       // will essentially "collapse" to this       // initializer call in the generated code       self.init(...)!     } else {       return nil       // need a way of emitting a more       // informational error message?     }   } } There's still a lot of open questions to think through, like should this only apply to literal conversions or any initializer signature where the arguments' value can be known at compile time, but I wanted to toss out a seedling of a different idea. I also don't know how much would have to change within the compiler to provide this level of compile-time evaluation. > **···** > > On Sat, Dec 17, 2016 at 5:57 AM Step C via swift-evolution \< swift-evolution@swift.org\> wrote: > > > 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 am using literals to mean > > values that are understood by the compiler.) > > > > - Step > > > > On Dec 16, 2016, at 9:46 PM, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > 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 relatively rare ObjC interop features". > > > > However, I would think that the general issue of compiler help to indicate > > when certain initializers are guaranteed to fail is the opposite of a > > "relatively rare interop feature" and deserves perhaps a more holistic > > treatment rather than a selector-like quick-fix for URLs only. > > > > On Fri, Dec 16, 2016 at 20:33 Micah Hainline \ \> wrote: > > > > 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 they're okay in much the same way you describe here. There was value > > in breaking that out differently though, partly because it makes very clear > > what will and what will not be validated. > > > > I don't think force-unwrapping is exactly an anti pattern, but it is one > > of the less desirable patterns, and I do think it should be avoided where > > cleanly possible. > > > > On Dec 16, 2016, at 8:14 PM, Xiaodi Wu \ wrote: > > > > 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: > > > > 1. The developer experience of using failable initializers invoked with > > hardcoded arguments is sub-par. For URL, or for any other type where > > success or failure of initialization is determined entirely by the > > arguments passed in, it would be nice to have the compiler tell you \_at > > compile time\_ if the hardcoded arguments are guaranteed to cause the > > initializer to return nil. I think this is quite an insightful point. > > > > 2. You do not like working with force unwrapping. While certainly entitled > > to that opinion, I do not think this opinion alone (since it is separable > > from (1)) can justify additions or subtractions to the language. Either > > force unwrapping is a legitimate part of the language--that is, the > > community that designs Swift can agree on specific patterns where its use > > is considered best practice--or it is an anti-pattern that should be > > deprecated and eventually removed. It cannot be a lingering yet fully > > supported first-class anti-pattern that we design standard and core library > > APIs actively to avoid. > > > > 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 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 to the language, > > which (just MHO) is rarely the best solution when a good alternative exists. > > > > Here, for instance, one could add compiler magic that warns at compile > > time that `URL(string: "notavalidurl")!` is guaranteed to fail. That could > > be a diagnostics/QoI improvement that almost certainly wouldn't require > > going through the evolution process. > > > > What I was trying to point out is that I agree with Derrick that the > > \_spelling\_ `URL(string: "[https://example.com/"\](https://example.com/"%5C))!` is perfectly fine and > > not in need of improvement, and that I disagree strongly that force > > unwrapping is problematic as a matter of style. > > > > 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. > > > > 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. > > > > When you use a URL, what would you do differently when a resource is > > unavailable versus when the URL is malformed, especially if you're > > hardcoding the URL? > > > > It does help to have one of them accounted for by the compiler if possible. > > > > I'm trying to teach some less experienced developers to think of > > force-unwrapping as a code smell, > > > > There have been a few people who have said a similar thing on the list, > > but I don't think this is the official line about force-unwrapping. Force > > unwrapping is an explicitly supported part of the language that has its > > uses. If you \*know\* at the time of writing that a failable initializer > > should never fail, then `!` is an expressive, clear, concise, entirely > > appropriate, and I would even say the \*best\* way of indicating that to your > > reader. > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` > > is one example of this usage, but not at all the only one. I have > > previously written, for example, `"L".cString(using: .utf8)!`. This is also > > no code smell, as what I'm doing is stating my absolute confidence (and > > indicating that confidence to the reader) that the letter L can be encoded > > using UTF-8. > > > > but it's not the best to have to say "except for URLs". I realize the > > utility of the proposed change is reasonably small, but I also think it's > > purely additive and consistent with the rest of the language. 🙂 > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > 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 that what you're after is compile-time checking of > > validity, I'm not convinced that it is materially useful. I also don't see > > how it's contributing to type safety. Perhaps you could illuminate what use > > case has persuaded you of these things? Here's my thinking: > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of a > > URL, it's a mistake that results in a plausible but unintended URL and a > > compile-time check for validity will not help at all. To guard against such > > an error, I need to write tests anyway and could never depend on the > > compiler. In fact, I'd imagine that doing anything useful with a URL--even > > a hardcoded one--will require some thought as to how to deal with error > > handling at runtime. How is it helpful to have only the lowest bar (a > > technically valid URL format) ensured at compile time instead of runtime? > > By contrast, Swift selectors help to guarantee that any particular function > > I'm referring to actually exists; when that is ensured at compile time, I > > know it will be the case at runtime. There's no corresponding guarantee by > > having a compile-time check for URL validity that the resource pointed to > > will actually exist. That the nonexistent resource was denoted by a string > > that had the correct format of a URL is cold comfort, no? > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > let url = #url("[https://example.com](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-evolution \< \> swift-evolution@swift.org\> wrote: > > > > 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 \< \> swift-evolution@swift.org\> wrote: > > > > \>\>\> > > > > \>\>\> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution \< \> swift-evolution@swift.org\> 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](https://example.com)")! > > > > \>\>\> > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a new > > > > \>\>\> macro structure similar to #selector, though I'm open to other ideas. > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > \>\>\> problems. That would look like this: > > > > \>\>\> > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > \>\>\> > > > > \>\>\> What does everyone think of that idea? > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > \>\>\> swift-evolution mailing list > > > > \>\>\> swift-evolution@swift.org > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \>\> > > > > \>\> > > > > \>\> I’d like to see something like that for file path URLs. For something > > so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > \>\> > > > > \>\> Charles > > > > \> > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the > > incredible pain is that even compile-time URLs to your own website are > > nullable URL? and you need to force-unwrap them. > > > > \> > > > > \>\> > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > \>\> swift-evolution mailing list > > > > \>\> swift-evolution@swift.org > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \> > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Micah\_Hainline](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Micah\_Hainline](https://forums.swift.org/u/Micah_Hainline)\ **Post date:** [December 19, 2016, 2:47pm UTC](https://forums.swift.org/t/url-literals/4728/25 "2016-12-19T14:47:45Z")
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 does not. Consider the resource being available at run time but not compile time. That applies to file urls and every other kind. Secondly, it would be dangerous on many levels. > **···** > > On Mon, Dec 19, 2016 at 3:39 AM, Xiaodi Wu \ wrote: > > > 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, which might fail validation. That's where I draw the line. > > > > > > I have seen some good developers "think" they "know" the value can't be > > > nil, and they were just wrong. > > > > Well, sure, but the fault originated with the good developer being wrong, > > not with `!`. All I'm saying is, there are legitimate use cases where one > > intends to have this behavior: > > > > ```swift > > guard let foo = bar else { > > fatalError() // Bye. > > } > > > > ``` > > > > In those cases, it is perfectly legitimate to write: > > > > ```swift > > let foo = bar! > > > > ``` > > > > But when we can specifically run a unit test with 0 inputs on the value, > > > > > then falsification of nullability is easy. > > > > > > -Ben > > > > > > Sent from my iPhone. > > > > > > On Dec 16, 2016, at 7:30 PM, Xiaodi Wu via swift-evolution \< \>\> swift-evolution@swift.org\> 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. > > > > > > > > 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. > > > > > > When you use a URL, what would you do differently when a resource is > > > unavailable versus when the URL is malformed, especially if you're > > > hardcoding the URL? > > > > > > It does help to have one of them accounted for by the compiler if > > > > > > > possible. > > > > > > > > I'm trying to teach some less experienced developers to think of > > > > force-unwrapping as a code smell, > > > > > > There have been a few people who have said a similar thing on the list, > > > but I don't think this is the official line about force-unwrapping. Force > > > unwrapping is an explicitly supported part of the language that has its > > > uses. If you \*know\* at the time of writing that a failable initializer > > > should never fail, then `!` is an expressive, clear, concise, entirely > > > appropriate, and I would even say the \*best\* way of indicating that to your > > > reader. > > > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` > > > is one example of this usage, but not at all the only one. I have > > > previously written, for example, `"L".cString(using: .utf8)!`. This is also > > > no code smell, as what I'm doing is stating my absolute confidence (and > > > indicating that confidence to the reader) that the letter L can be encoded > > > using UTF-8. > > > > > > but it's not the best to have to say "except for URLs". I realize the > > > > > > > utility of the proposed change is reasonably small, but I also think it's > > > > purely additive and consistent with the rest of the language. 🙂 > > > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > > > > > 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 that what you're after is compile-time checking of > > > > validity, I'm not convinced that it is materially useful. I also don't see > > > > how it's contributing to type safety. Perhaps you could illuminate what use > > > > case has persuaded you of these things? Here's my thinking: > > > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of > > > > a URL, it's a mistake that results in a plausible but unintended URL and a > > > > compile-time check for validity will not help at all. To guard against such > > > > an error, I need to write tests anyway and could never depend on the > > > > compiler. In fact, I'd imagine that doing anything useful with a URL--even > > > > a hardcoded one--will require some thought as to how to deal with error > > > > handling at runtime. How is it helpful to have only the lowest bar (a > > > > technically valid URL format) ensured at compile time instead of runtime? > > > > By contrast, Swift selectors help to guarantee that any particular function > > > > I'm referring to actually exists; when that is ensured at compile time, I > > > > know it will be the case at runtime. There's no corresponding guarantee by > > > > having a compile-time check for URL validity that the resource pointed to > > > > will actually exist. That the nonexistent resource was denoted by a string > > > > that had the correct format of a URL is cold comfort, no? > > > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > > > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > > > > > > > let url = #url("[https://example.com](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-evolution \< \>\>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > > > > 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 \< \>\>\>\>\> charlie@charliemonroe.net\> wrote: > > > > > > \> > > > > > > \> > > > > > > \>\>\> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution \< \>\>\>\>\> swift-evolution@swift.org\> wrote: > > > > > > \>\>\> > > > > > > \>\>\> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution \< \>\>\>\>\> swift-evolution@swift.org\> 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](https://example.com)")! > > > > > > \>\>\> > > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a > > > > > > new > > > > > > \>\>\> macro structure similar to #selector, though I'm open to other > > > > > > ideas. > > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > > \>\>\> problems. That would look like this: > > > > > > \>\>\> > > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > > > \>\>\> > > > > > > \>\>\> What does everyone think of that idea? > > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > \>\>\> swift-evolution mailing list > > > > > > \>\>\> swift-evolution@swift.org > > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \>\> > > > > > > \>\> > > > > > > \>\> I’d like to see something like that for file path URLs. For > > > > > > something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > > \>\> > > > > > > \>\> Charles > > > > > > \> > > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the > > > > > > incredible pain is that even compile-time URLs to your own website are > > > > > > nullable URL? and you need to force-unwrap them. > > > > > > \> > > > > > > \>\> > > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > \>\> swift-evolution mailing list > > > > > > \>\> swift-evolution@swift.org > > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \> > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [December 17, 2016, 4:55pm UTC](https://forums.swift.org/t/url-literals/4728/26 "2016-12-17T16:55:25Z")
+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 > > \* 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 restricted subset of the language that would be evaluated at statically at compile time. It's getting into C++ "constexpr" territory, but I wouldn't want to settle for something that tightly couples special behavior to just a few types. > > > > Quick back of the napkin sketch, I haven't thought too much about syntax details yet: > > > > struct URL: ExpressibleByStringLiteral { > >   // the #, or something similar, indicates this > >   // is compile-time evaluation > >   #init?(\_ stringLiteral: StaticString) { > >     // validate the string. We'd be able to use > >     // loops and access individual characters > >     // in the static string... regexes would be > >     // trickier. > >     if valid { > >       // if we get here, everything we did > >       // will essentially "collapse" to this > >       // initializer call in the generated code > >       self.init(...)! > >     } else { > >       return nil > >       // need a way of emitting a more > >       // informational error message? > >     } > >   } > > } > > > > There's still a lot of open questions to think through, like should this only apply to literal conversions or any initializer signature where the arguments' value can be known at compile time, but I wanted to toss out a seedling of a different idea. I also don't know how much would have to change within the compiler to provide this level of compile-time evaluation. > > > > On Sat, Dec 17, 2016 at 5:57 AM Step C via swift-evolution \\> wrote: > > 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 am using literals to mean values that are understood by the compiler.) > > > > - Step > > > > On Dec 16, 2016, at 9:46 PM, Xiaodi Wu via swift-evolution \\> wrote: > > > > > 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 relatively rare ObjC interop features". > > > > > > However, I would think that the general issue of compiler help to indicate when certain initializers are guaranteed to fail is the opposite of a "relatively rare interop feature" and deserves perhaps a more holistic treatment rather than a selector-like quick-fix for URLs only. > > > > > > On Fri, Dec 16, 2016 at 20:33 Micah Hainline \\> wrote: > > > 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 they're okay in much the same way you describe here. There was value in breaking that out differently though, partly because it makes very clear what will and what will not be validated. > > > > > > I don't think force-unwrapping is exactly an anti pattern, but it is one of the less desirable patterns, and I do think it should be avoided where cleanly possible. > > > > > > On Dec 16, 2016, at 8:14 PM, Xiaodi Wu \\> wrote: > > > > > > > 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: > > > > > > > > 1. The developer experience of using failable initializers invoked with hardcoded arguments is sub-par. For URL, or for any other type where success or failure of initialization is determined entirely by the arguments passed in, it would be nice to have the compiler tell you \_at compile time\_ if the hardcoded arguments are guaranteed to cause the initializer to return nil. I think this is quite an insightful point. > > > > > > > > 2. You do not like working with force unwrapping. While certainly entitled to that opinion, I do not think this opinion alone (since it is separable from (1)) can justify additions or subtractions to the language. Either force unwrapping is a legitimate part of the language--that is, the community that designs Swift can agree on specific patterns where its use is considered best practice--or it is an anti-pattern that should be deprecated and eventually removed. It cannot be a lingering yet fully supported first-class anti-pattern that we design standard and core library APIs actively to avoid. > > > > > > > > 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 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 to the language, which (just MHO) is rarely the best solution when a good alternative exists. > > > > > > > > > > Here, for instance, one could add compiler magic that warns at compile time that `URL(string: "notavalidurl")!` is guaranteed to fail. That could be a diagnostics/QoI improvement that almost certainly wouldn't require going through the evolution process. > > > > > > > > > > What I was trying to point out is that I agree with Derrick that the \_spelling\_ `URL(string: "[https://example.com/"\](https://example.com/"%5C))!` is perfectly fine and not in need of improvement, and that I disagree strongly that force unwrapping is problematic as a matter of style. > > > > > > > > > > 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. > > > > > > > > > > > > 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. > > > > > > > > > > > > When you use a URL, what would you do differently when a resource is unavailable versus when the URL is malformed, especially if you're hardcoding the URL? > > > > > > > > > > > > It does help to have one of them accounted for by the compiler if possible. > > > > > > > > > > > > I'm trying to teach some less experienced developers to think of force-unwrapping as a code smell, > > > > > > > > > > > > There have been a few people who have said a similar thing on the list, but I don't think this is the official line about force-unwrapping. Force unwrapping is an explicitly supported part of the language that has its uses. If you \*know\* at the time of writing that a failable initializer should never fail, then `!` is an expressive, clear, concise, entirely appropriate, and I would even say the \*best\* way of indicating that to your reader. > > > > > > > > > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` is one example of this usage, but not at all the only one. I have previously written, for example, `"L".cString(using: .utf8)!`. This is also no code smell, as what I'm doing is stating my absolute confidence (and indicating that confidence to the reader) that the letter L can be encoded using UTF-8. > > > > > > > > > > > > but it's not the best to have to say "except for URLs". I realize the utility of the proposed change is reasonably small, but I also think it's purely additive and consistent with the rest of the language. 🙂 > > > > > > > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \\> wrote: > > > > > > > > > > > > > On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution \\> 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 that what you're after is compile-time checking of validity, I'm not convinced that it is materially useful. I also don't see how it's contributing to type safety. Perhaps you could illuminate what use case has persuaded you of these things? Here's my thinking: > > > > > > > > > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of a URL, it's a mistake that results in a plausible but unintended URL and a compile-time check for validity will not help at all. To guard against such an error, I need to write tests anyway and could never depend on the compiler. In fact, I'd imagine that doing anything useful with a URL--even a hardcoded one--will require some thought as to how to deal with error handling at runtime. How is it helpful to have only the lowest bar (a technically valid URL format) ensured at compile time instead of runtime? By contrast, Swift selectors help to guarantee that any particular function I'm referring to actually exists; when that is ensured at compile time, I know it will be the case at runtime. There's no corresponding guarantee by having a compile-time check for URL validity that the resource pointed to will actually exist. That the nonexistent resource was denoted by a string that had the correct format of a URL is cold comfort, no? > > > > > > > > > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \\> wrote: > > > > > > > > > > > > > > > let url = URL(string: "[https://example.com](https://example.com) \<[https://example.com/>"\](https://example.com/>"%5C))! > > > > > > > > > > > > > > > > let url = #url("[https://example.com](https://example.com) \<[https://example.com/>"\](https://example.com/>"%5C)) > > > > > > > > > > > > > > > > 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-evolution \\> wrote: > > > > > > > > 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 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](https://example.com) \<[https://example.com/>"\](https://example.com/>"%5C))! > > > > > > > > > > > > > > > > \>\>\> > > > > > > > > > > > > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a new > > > > > > > > > > > > > > > > \>\>\> macro structure similar to #selector, though I'm open to other ideas. > > > > > > > > > > > > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > > > > > > > > > > > > \>\>\> problems. That would look like this: > > > > > > > > > > > > > > > > \>\>\> > > > > > > > > > > > > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com) \<[https://example.com/>"\](https://example.com/>"%5C)) > > > > > > > > > > > > > > > > \>\>\> > > > > > > > > > > > > > > > > \>\>\> What does everyone think of that idea? > > > > > > > > > > > > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > > > > > > > > > \>\>\> swift-evolution mailing list > > > > > > > > > > > > > > > > \>\>\> swift-evolution@swift.org \ > > > > > > > > > > > > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > > > \>\> > > > > > > > > > > > > > > > > \>\> > > > > > > > > > > > > > > > > \>\> I’d like to see something like that for file path URLs. For something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > > > > > > > > > > > > \>\> > > > > > > > > > > > > > > > > \>\> Charles > > > > > > > > > > > > > > > > \> > > > > > > > > > > > > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the incredible pain is that even compile-time URLs to your own website are nullable URL? and you need to force-unwrap them. > > > > > > > > > > > > > > > > \> > > > > > > > > > > > > > > > > \>\> > > > > > > > > > > > > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > > > > > > > > > \>\> swift-evolution mailing list > > > > > > > > > > > > > > > > \>\> swift-evolution@swift.org \ > > > > > > > > > > > > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > > > \> > > > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > > > > > > > > > swift-evolution mailing list > > > > > > > > > > > > > > > > swift-evolution@swift.org \ > > > > > > > > > > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > > > > > > > swift-evolution mailing list > > > > > > > > > > > > > > swift-evolution@swift.org \ > > > > > > > > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\ **Post date:** [December 17, 2016, 6:59pm UTC](https://forums.swift.org/t/url-literals/4728/27 "2016-12-17T18:59:29Z")
> 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 subset of the language, and having the compiler evaluate those at compile time when all arguments are literals. That way, you'd get compile-time warnings of failable initializers guaranteed to fail \_without\_ any changes in syntax to the language. It wouldn't have to be restricted to a subset of the language; just to functions whose evaluation doesn't depend on anything that happens at runtime. Any "@pure" (or whatever... it's easier to type on my phone than "@constantExpression") function should work fine, if we define a "pure" function to be something like: 1) Doesn't mutate anything outside its own scope 2) Doesn't call anything involving rand() or other non-deterministic functions 3) Doesn't have a result that depends on the host or target architectures (I'm not sure if this extends to FP subtleties) 4) Doesn't reference any non-local variables which don't themselves have a value that's either itself a literal or the result of evaluating a "pure" function 5) Doesn't call any other functions which aren't themselves "pure", or instantiate any variables using inits that aren't "pure" Since there's already a Swift REPL, at least conceptually speaking, this doesn't seem too hard (although it does raise the bar a bit for what it takes to have a "full" Swift compiler, since it'd then depend on having a working REPL on the host platform, which IIRC wasn't the case on Linux for a while... dunno, maybe this is a non-issue). - Dave Sweeris > **···** > > Sent from my iPhone > > > On Dec 17, 2016, at 09:47, Xiaodi Wu via swift-evolution \ wrote: ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [December 17, 2016, 5:47pm UTC](https://forums.swift.org/t/url-literals/4728/28 "2016-12-17T17:47:49Z")
+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 subset of the language, and having the compiler evaluate those at compile time when all arguments are literals. That way, you'd get compile-time warnings of failable initializers guaranteed to fail \_without\_ any changes in syntax to the language. Definitely, I agree with Tony that it shouldn't be "magical" to the end user, shouldn't be restricted to specific types and should be implementable by any user in their own type. In fact, I'd say that specific compiler knowledge probably should be a non-starter in the case of URL, since it's a Foundation type and the magic would have to be in the compiler. > **···** > > On Sat, Dec 17, 2016 at 10:55 AM, Matthew Johnson \ wrote: > > > +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 \< \> swift-evolution@swift.org\> wrote: > > > > 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 restricted subset of the language that would be > > evaluated at statically at compile time. It's getting into C++ "constexpr" > > territory, but I wouldn't want to settle for something that tightly couples > > special behavior to just a few types. > > > > Quick back of the napkin sketch, I haven't thought too much about syntax > > details yet: > > > > struct URL: ExpressibleByStringLiteral { > >   // the #, or something similar, indicates this > >   // is compile-time evaluation > >   #init?(\_ stringLiteral: StaticString) { > >     // validate the string. We'd be able to use > >     // loops and access individual characters > >     // in the static string... regexes would be > >     // trickier. > >     if valid { > >       // if we get here, everything we did > >       // will essentially "collapse" to this > >       // initializer call in the generated code > >       self.init(...)! > >     } else { > >       return nil > >       // need a way of emitting a more > >       // informational error message? > >     } > >   } > > } > > > > There's still a lot of open questions to think through, like should this > > only apply to literal conversions or any initializer signature where the > > arguments' value can be known at compile time, but I wanted to toss out a > > seedling of a different idea. I also don't know how much would have to > > change within the compiler to provide this level of compile-time evaluation. > > > > On Sat, Dec 17, 2016 at 5:57 AM Step C via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > > 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 am using literals > > > to mean values that are understood by the compiler.) > > > > > > - Step > > > > > > On Dec 16, 2016, at 9:46 PM, Xiaodi Wu via swift-evolution \< \>\> swift-evolution@swift.org\> wrote: > > > > > > 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 relatively rare ObjC interop features". > > > > > > However, I would think that the general issue of compiler help to > > > indicate when certain initializers are guaranteed to fail is the opposite > > > of a "relatively rare interop feature" and deserves perhaps a more holistic > > > treatment rather than a selector-like quick-fix for URLs only. > > > > > > On Fri, Dec 16, 2016 at 20:33 Micah Hainline \ \>\> wrote: > > > > > > 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 they're okay in much the same way you describe here. There was value > > > in breaking that out differently though, partly because it makes very clear > > > what will and what will not be validated. > > > > > > I don't think force-unwrapping is exactly an anti pattern, but it is one > > > of the less desirable patterns, and I do think it should be avoided where > > > cleanly possible. > > > > > > On Dec 16, 2016, at 8:14 PM, Xiaodi Wu \ wrote: > > > > > > 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: > > > > > > 1. The developer experience of using failable initializers invoked with > > > hardcoded arguments is sub-par. For URL, or for any other type where > > > success or failure of initialization is determined entirely by the > > > arguments passed in, it would be nice to have the compiler tell you \_at > > > compile time\_ if the hardcoded arguments are guaranteed to cause the > > > initializer to return nil. I think this is quite an insightful point. > > > > > > 2. You do not like working with force unwrapping. While certainly > > > entitled to that opinion, I do not think this opinion alone (since it is > > > separable from (1)) can justify additions or subtractions to the language. > > > Either force unwrapping is a legitimate part of the language--that is, the > > > community that designs Swift can agree on specific patterns where its use > > > is considered best practice--or it is an anti-pattern that should be > > > deprecated and eventually removed. It cannot be a lingering yet fully > > > supported first-class anti-pattern that we design standard and core library > > > APIs actively to avoid. > > > > > > 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 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 to the language, > > > which (just MHO) is rarely the best solution when a good alternative exists. > > > > > > Here, for instance, one could add compiler magic that warns at compile > > > time that `URL(string: "notavalidurl")!` is guaranteed to fail. That could > > > be a diagnostics/QoI improvement that almost certainly wouldn't require > > > going through the evolution process. > > > > > > What I was trying to point out is that I agree with Derrick that the > > > \_spelling\_ `URL(string: "[https://example.com/"\](https://example.com/"%5C))!` is perfectly fine and > > > not in need of improvement, and that I disagree strongly that force > > > unwrapping is problematic as a matter of style. > > > > > > 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. > > > > > > 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. > > > > > > When you use a URL, what would you do differently when a resource is > > > unavailable versus when the URL is malformed, especially if you're > > > hardcoding the URL? > > > > > > It does help to have one of them accounted for by the compiler if > > > possible. > > > > > > I'm trying to teach some less experienced developers to think of > > > force-unwrapping as a code smell, > > > > > > There have been a few people who have said a similar thing on the list, > > > but I don't think this is the official line about force-unwrapping. Force > > > unwrapping is an explicitly supported part of the language that has its > > > uses. If you \*know\* at the time of writing that a failable initializer > > > should never fail, then `!` is an expressive, clear, concise, entirely > > > appropriate, and I would even say the \*best\* way of indicating that to your > > > reader. > > > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` > > > is one example of this usage, but not at all the only one. I have > > > previously written, for example, `"L".cString(using: .utf8)!`. This is also > > > no code smell, as what I'm doing is stating my absolute confidence (and > > > indicating that confidence to the reader) that the letter L can be encoded > > > using UTF-8. > > > > > > but it's not the best to have to say "except for URLs". I realize the > > > utility of the proposed change is reasonably small, but I also think it's > > > purely additive and consistent with the rest of the language. 🙂 > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > > > 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 that what you're after is compile-time checking of > > > validity, I'm not convinced that it is materially useful. I also don't see > > > how it's contributing to type safety. Perhaps you could illuminate what use > > > case has persuaded you of these things? Here's my thinking: > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of a > > > URL, it's a mistake that results in a plausible but unintended URL and a > > > compile-time check for validity will not help at all. To guard against such > > > an error, I need to write tests anyway and could never depend on the > > > compiler. In fact, I'd imagine that doing anything useful with a URL--even > > > a hardcoded one--will require some thought as to how to deal with error > > > handling at runtime. How is it helpful to have only the lowest bar (a > > > technically valid URL format) ensured at compile time instead of runtime? > > > By contrast, Swift selectors help to guarantee that any particular function > > > I'm referring to actually exists; when that is ensured at compile time, I > > > know it will be the case at runtime. There's no corresponding guarantee by > > > having a compile-time check for URL validity that the resource pointed to > > > will actually exist. That the nonexistent resource was denoted by a string > > > that had the correct format of a URL is cold comfort, no? > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > > > let url = #url("[https://example.com](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-evolution \< \>\> swift-evolution@swift.org\> wrote: > > > > > > 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 \< \>\> swift-evolution@swift.org\> wrote: > > > > > > \>\>\> > > > > > > \>\>\> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution \< \>\> swift-evolution@swift.org\> 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](https://example.com)")! > > > > > > \>\>\> > > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce a new > > > > > > \>\>\> macro structure similar to #selector, though I'm open to other ideas. > > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > > \>\>\> problems. That would look like this: > > > > > > \>\>\> > > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > > > \>\>\> > > > > > > \>\>\> What does everyone think of that idea? > > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > \>\>\> swift-evolution mailing list > > > > > > \>\>\> swift-evolution@swift.org > > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \>\> > > > > > > \>\> > > > > > > \>\> I’d like to see something like that for file path URLs. For something > > > so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > > \>\> > > > > > > \>\> Charles > > > > > > \> > > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the > > > incredible pain is that even compile-time URLs to your own website are > > > nullable URL? and you need to force-unwrap them. > > > > > > \> > > > > > > \>\> > > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > \>\> swift-evolution mailing list > > > > > > \>\> swift-evolution@swift.org > > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \> > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\ **Post date:** [December 17, 2016, 9:20pm UTC](https://forums.swift.org/t/url-literals/4728/29 "2016-12-17T21:20:00Z")
> 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 that shows how I'd envision it working. - Dave Sweeris > **···** > > Sent from my iPhone > > > On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution \ wrote: ---
**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\ **Post date:** [December 17, 2016, 9:27pm UTC](https://forums.swift.org/t/url-literals/4728/30 "2016-12-17T21:27:59Z")
> Sent from my iPhone > > > 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 that shows how I'd envision it working. Oh, and to be clear, I'm not trying to "claim" this or anything... if anyone else has ideas, please post them! The more the merrier. > **···** > > Sent from my iPhone > > > On Dec 17, 2016, at 13:20, David Sweeris \ wrote: > > > > > On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution \ wrote: ---
**Author:** ![Micah\_Hainline](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Micah\_Hainline](https://forums.swift.org/u/Micah_Hainline)\ **Post date:** [December 17, 2016, 9:44pm UTC](https://forums.swift.org/t/url-literals/4728/31 "2016-12-17T21:44:08Z")
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, 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 special init method would look like. > > > > > > I can't do it now, but I'll try post one before tomorrow that shows how I'd envision it working. > > > > Oh, and to be clear, I'm not trying to "claim" this or anything... if anyone else has ideas, please post them! The more the merrier. ---
**Author:** ![Anton\_Zhilin](https://avatars.discourse-cdn.com/v4/letter/a/e79b87/32.png) [@Anton\_Zhilin](https://forums.swift.org/u/Anton_Zhilin)\ **Post date:** [December 17, 2016, 7:15pm UTC](https://forums.swift.org/t/url-literals/4728/32 "2016-12-17T19:15:00Z")
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 at compilation time (even if it takes a lot of time, even in debug builds), we add @pure to the declaration. It wouldn't have to be restricted to a subset of the language; just to > functions whose evaluation doesn't depend on anything that happens at > runtime. > > Any "@pure" (or whatever... it's easier to type on my phone than > "@constantExpression") function should work fine, if we define a "pure" > function to be something like: > 1) Doesn't mutate anything outside its own scope > 2) Doesn't call anything involving rand() or other non-deterministic > functions > 3) Doesn't have a result that depends on the host or target architectures > (I'm not sure if this extends to FP subtleties) > 4) Doesn't reference any non-local variables which don't themselves have a > value that's either itself a literal or the result of evaluating a "pure" > function > 5) Doesn't call any other functions which aren't themselves "pure", or > instantiate any variables using inits that aren't "pure" > > Since there's already a Swift REPL, at least conceptually speaking, this > doesn't seem too hard (although it does raise the bar a bit for what it > takes to have a "full" Swift compiler, since it'd then depend on having a > working REPL on the host platform, which IIRC wasn't the case on Linux for > a while... dunno, maybe this is a non-issue). ​ > **···** > > 2016-12-17 21:59 GMT+03:00 David Sweeris via swift-evolution \< swift-evolution@swift.org\>: ---
**Author:** ![Step](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/step/32/305_2.png) [@Step](https://forums.swift.org/u/Step)\ **Post date:** [December 18, 2016, 3:46am UTC](https://forums.swift.org/t/url-literals/4728/33 "2016-12-18T03:46:10Z")
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 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, 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 special init method would look like. > > > > > > > > I can't do it now, but I'll try post one before tomorrow that shows how I'd envision it working. > > > > > > Oh, and to be clear, I'm not trying to "claim" this or anything... if anyone else has ideas, please post them! The more the merrier. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\ **Post date:** [December 19, 2016, 7:41am UTC](https://forums.swift.org/t/url-literals/4728/34 "2016-12-19T07:41:00Z")
Sorry this took so long… the weekend kinda got away from me. Anyway, I was thinking something like this (which has been very simplified on account of my regexing being sub-sketchy, and me not knowing exactly what’s valid in an URL anyway): #literalpatterns += (name: “URLLiteralType”, components: (name: url, type: StringLiteralType, pattern: “(http|https)://(www.)?[a-z|A-Z|0-9]+.(com|org|net)(/[a-z|A-Z|0-9]+)\*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”), protocol: ExpressibleByURLLiteral) This would let the compiler know pretty much everything it needs to know… that the “new” type is called “URLLiteralType", that it starts out life as young StringLiteralType with a bright future in the computer industry, that in order to succeed it has to match a given pattern, and what protocol a type has to conform to in order to use an URLLiteral. In practice, the compiler would synthesize a struct containing the specified members and validate the literal with the specified pattern before making an “instance” of it (since we’re talking about literals and compile-time code here, I’m pretty sure that “instance" the wrong terminology… pardon my ignorance) struct URLLiteralType: {     let url: StringLiteralType } A tuple would be better, IMHO, but according to the playground, single-element tuples can’t have element labels. As for the implementation of the init function: init(urlLiteral value: URLLiteralType) {     let urlString = value.url     //Do whatever URL is doing now, except there’s no need to check for errors since the compiler pre-validated it for us } If it’d be more useful, the pattern could be split into multiple pieces: #literalpatterns += (name: “URLLiteralType”,                      components: ((name: “`protocol`", type: StringLiteralType, pattern: “(http|https)”),                                   (name: \_, type: StringLiteralType, pattern: “://”),                                   (name: “domain", type: StringLiteralType, pattern: “(www.)?[a-z|A-Z|0-9]+.(com|org|net)”),                                   (name: “path”, type: StringLiteralType, pattern: "(/[a-z|A-Z|0-9]+)\*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”))                      protocol: ExpressibleByURLLiteral) This would result in URLLiteralType looking like this: struct URLLiteralType: {     let `protocol`: StringLiteralType     let domain: StringLiteralType     let path: StringLiteralType } And in the init would start out like this: init(urlLiteral value: URLLiteralType) {     let protocolType = value.protocol     let domain = value.domain     let path = value.path     //Do whatever with the components } The “base” types of literals like Int or String that don’t refine pre-existing literal types would still need a bit of compiler magic (or at least a different mechanism for becoming actual types), but as long as a type doesn’t take advantage of reference semantics in its stored properties or something, I \*think\* pretty much any data type could become “literalizeable” with something like this. Oh, and there’s nothing particularly magical about regular expressions as far as this idea is concerned; they’re just usually the first thing that comes to mind when I think of pattern matching in a string. I know this looks like a lot of code, but the scary-looking parts with the regex stuff only has to be written once for each “type” of literal… types that want to be expressible by such a literal just have to write an init function. While I was writing this up, it occurred to me that another solution would be to have a set of "ExpressibleByValidated\*Literal” protocols, where the init is failable and has to be @pure/@constexpr/@whateverthecompilerneedstorunitatcompiletime. That way the literal can be validated simply by calling the init and checking if it returns nil. Make `URL` conform to `ExpressibleByValidatedStringLiteral`, and you'll get the complie-time validation functionality just by copying whatever’s in the current `URL.init?(string: String)` function. - Dave Sweeris > **···** > > > 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. ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [December 19, 2016, 6:39pm UTC](https://forums.swift.org/t/url-literals/4728/35 "2016-12-19T18:39:04Z")
> 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 does not. Consider the resource being available at run time but > not compile time. That applies to file urls and every other kind. File literals already do this, don't they? > **···** > > On Mon, Dec 19, 2016 at 8:47 AM, Micah Hainline via swift-evolution \< swift-evolution@swift.org\> wrote: > > > Secondly, it would be dangerous on many levels. > > > > On Mon, Dec 19, 2016 at 3:39 AM, Xiaodi Wu \ wrote: > > > > > 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, which might fail validation. That's where I draw the line. > > > > > > > > I have seen some good developers "think" they "know" the value can't be > > > > nil, and they were just wrong. > > > > > > Well, sure, but the fault originated with the good developer being wrong, > > > not with `!`. All I'm saying is, there are legitimate use cases where one > > > intends to have this behavior: > > > > > > ```swift > > > guard let foo = bar else { > > > fatalError() // Bye. > > > } > > > > > > ``` > > > > > > In those cases, it is perfectly legitimate to write: > > > > > > ```swift > > > let foo = bar! > > > > > > ``` > > > > > > But when we can specifically run a unit test with 0 inputs on the value, > > > > > > > then falsification of nullability is easy. > > > > > > > > -Ben > > > > > > > > Sent from my iPhone. > > > > > > > > On Dec 16, 2016, at 7:30 PM, Xiaodi Wu via swift-evolution \< \>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline \< \>\>\> micah.hainline@gmail.com\> 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 related. > > > > > > > > When you use a URL, what would you do differently when a resource is > > > > unavailable versus when the URL is malformed, especially if you're > > > > hardcoding the URL? > > > > > > > > It does help to have one of them accounted for by the compiler if > > > > > > > > > possible. > > > > > > > > > > I'm trying to teach some less experienced developers to think of > > > > > force-unwrapping as a code smell, > > > > > > > > There have been a few people who have said a similar thing on the list, > > > > but I don't think this is the official line about force-unwrapping. Force > > > > unwrapping is an explicitly supported part of the language that has its > > > > uses. If you \*know\* at the time of writing that a failable initializer > > > > should never fail, then `!` is an expressive, clear, concise, entirely > > > > appropriate, and I would even say the \*best\* way of indicating that to your > > > > reader. > > > > > > > > It should be noted that `let url = URL(string: "[http://example.com/"\](http://example.com/"%5C))!` > > > > is one example of this usage, but not at all the only one. I have > > > > previously written, for example, `"L".cString(using: .utf8)!`. This is also > > > > no code smell, as what I'm doing is stating my absolute confidence (and > > > > indicating that confidence to the reader) that the letter L can be encoded > > > > using UTF-8. > > > > > > > > but it's not the best to have to say "except for URLs". I realize the > > > > > > > > > utility of the proposed change is reasonably small, but I also think it's > > > > > purely additive and consistent with the rest of the language. 🙂 > > > > > > > > > > On Dec 16, 2016, at 6:45 PM, Xiaodi Wu \ wrote: > > > > > > > > > > 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 that what you're after is compile-time checking of > > > > > validity, I'm not convinced that it is materially useful. I also don't see > > > > > how it's contributing to type safety. Perhaps you could illuminate what use > > > > > case has persuaded you of these things? Here's my thinking: > > > > > > > > > > Nine times out of ten when I mistype a URL, or paste only a fragment of > > > > > a URL, it's a mistake that results in a plausible but unintended URL and a > > > > > compile-time check for validity will not help at all. To guard against such > > > > > an error, I need to write tests anyway and could never depend on the > > > > > compiler. In fact, I'd imagine that doing anything useful with a URL--even > > > > > a hardcoded one--will require some thought as to how to deal with error > > > > > handling at runtime. How is it helpful to have only the lowest bar (a > > > > > technically valid URL format) ensured at compile time instead of runtime? > > > > > By contrast, Swift selectors help to guarantee that any particular function > > > > > I'm referring to actually exists; when that is ensured at compile time, I > > > > > know it will be the case at runtime. There's no corresponding guarantee by > > > > > having a compile-time check for URL validity that the resource pointed to > > > > > will actually exist. That the nonexistent resource was denoted by a string > > > > > that had the correct format of a URL is cold comfort, no? > > > > > > > > > > On Dec 16, 2016, at 5:50 PM, Derrick Ho \ wrote: > > > > > > > > > > > let url = URL(string: "[https://example.com](https://example.com)")! > > > > > > > > > > > > let url = #url("[https://example.com](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-evolution \< \>\>\>\>\> swift-evolution@swift.org\> wrote: > > > > > > > > > > > > > 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 \< \>\>\>\>\>\> charlie@charliemonroe.net\> wrote: > > > > > > > \> > > > > > > > \> > > > > > > > \>\>\> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution \< \>\>\>\>\>\> swift-evolution@swift.org\> wrote: > > > > > > > \>\>\> > > > > > > > \>\>\> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution \< \>\>\>\>\>\> swift-evolution@swift.org\> 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](https://example.com)")! > > > > > > > \>\>\> > > > > > > > \>\>\> The cleanest way I can think of doing that would be to introduce > > > > > > > a new > > > > > > > \>\>\> macro structure similar to #selector, though I'm open to other > > > > > > > ideas. > > > > > > > \>\>\> I would think it should take a quoted literal string to avoid > > > > > > > \>\>\> problems. That would look like this: > > > > > > > \>\>\> > > > > > > > \>\>\> let url: URL = #url("[https://example.com](https://example.com)") > > > > > > > \>\>\> > > > > > > > \>\>\> What does everyone think of that idea? > > > > > > > \>\>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > \>\>\> swift-evolution mailing list > > > > > > > \>\>\> swift-evolution@swift.org > > > > > > > \>\>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > \>\> > > > > > > > \>\> > > > > > > > \>\> I’d like to see something like that for file path URLs. For > > > > > > > something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose. > > > > > > > \>\> > > > > > > > \>\> Charles > > > > > > > \> > > > > > > > \> Yes, but it's not a nullable initializer. With URL(string:) the > > > > > > > incredible pain is that even compile-time URLs to your own website are > > > > > > > nullable URL? and you need to force-unwrap them. > > > > > > > \> > > > > > > > \>\> > > > > > > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > \>\> swift-evolution mailing list > > > > > > > \>\> swift-evolution@swift.org > > > > > > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > \> > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![David\_Sweeris](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_sweeris/32/31302_2.png) [@David\_Sweeris](https://forums.swift.org/u/David_Sweeris)\ **Post date:** [December 17, 2016, 9:14pm UTC](https://forums.swift.org/t/url-literals/4728/36 "2016-12-17T21:14:43Z")
Yeah, it seems like it'd be fairly straightforward to infer a function's "pureness" for value-type arguments and variables by annotating functions like rand() and such as "@hassideeffects" (which is a very poor wording, given that we don't want the @ stuff to be camelCase). It'd be harder for reference types, since their mutating functions aren't marked as such. We could probably get away with marking known-"bad" functions as "@whatever", use "@pure" for functions which \*need\* to be used that way, and let the compiler try to figure out the validity of using other, unannotated functions in a constant expression. Yes, I'm aware this could impact compile times, but we're just talking about assigning literals here... it doesn't need to be done for every line of code, and the functions in question aren't likely to be too complex. Presumably the results would get cached along with the other incremental compilation data (I think that's the right term), as well. Regarding terminology, there's a subtle difference between my list of constraints and what I'd normally associate with "pure" in the functional programming sense of the word... Specifically, in the FP meaning, I'd change #4 to "doesn't access any non-local variables" (which would make #1 redundant). Because of that, if this goes to a formal proposal, I prefer to use something else. "@constexpr" works for me, but I don't actually have much of an opinion on the topic, other than "@pure", IMHO, should loosely refer to code that's safely auto-parallelizable, reentrant, memoizable, etc (which is all a whole 'nother topic, but I wanted to reserve the word, so to speak). - Dave Sweeris > **···** > > > 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 function. > > If we want to require that some variable is computed at compilation time (even if it takes a lot of time, even in debug builds), we add @pure to the declaration. > > > > 2016-12-17 21:59 GMT+03:00 David Sweeris via swift-evolution \: > > > > > It wouldn't have to be restricted to a subset of the language; just to functions whose evaluation doesn't depend on anything that happens at runtime. > > > > > > Any "@pure" (or whatever... it's easier to type on my phone than "@constantExpression") function should work fine, if we define a "pure" function to be something like: > > > 1) Doesn't mutate anything outside its own scope > > > 2) Doesn't call anything involving rand() or other non-deterministic functions > > > 3) Doesn't have a result that depends on the host or target architectures (I'm not sure if this extends to FP subtleties) > > > 4) Doesn't reference any non-local variables which don't themselves have a value that's either itself a literal or the result of evaluating a "pure" function > > > 5) Doesn't call any other functions which aren't themselves "pure", or instantiate any variables using inits that aren't "pure" > > > > > > Since there's already a Swift REPL, at least conceptually speaking, this doesn't seem too hard (although it does raise the bar a bit for what it takes to have a "full" Swift compiler, since it'd then depend on having a working REPL on the host platform, which IIRC wasn't the case on Linux for a while... dunno, maybe this is a non-issue). ---
**Author:** ![Micah\_Hainline](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@Micah\_Hainline](https://forums.swift.org/u/Micah_Hainline)\ **Post date:** [December 17, 2016, 9:12pm UTC](https://forums.swift.org/t/url-literals/4728/37 "2016-12-17T21:12:54Z")
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 you're talking about compilation. I'm a little worried about things like cyclical references--not knowing if one class compiles until you've run code from another class, or even another library. Is it clear that the concept of @pure is sufficient for this? I FEEL like this is opening the door too far, at least a little. If we did do something like this as more than a one-off for URL however the external API looks we still would need to talk about the internal mechanics of how something can be marked as a compile error. Is it something like a special throw happening inside the code? Is there a precompiler-type directive denoting code that executes inside the block happens only at compile time? I'd love a fleshed out elegant example for URL that shows what a complete implementation of that special init method would look like. > **···** > > > On Dec 17, 2016, at 1:15 PM, Anton Zhilin via swift-evolution \ 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 function. > > If we want to require that some variable is computed at compilation time (even if it takes a lot of time, even in debug builds), we add @pure to the declaration. > > > > 2016-12-17 21:59 GMT+03:00 David Sweeris via swift-evolution \: > > > > > It wouldn't have to be restricted to a subset of the language; just to functions whose evaluation doesn't depend on anything that happens at runtime. > > > > > > Any "@pure" (or whatever... it's easier to type on my phone than "@constantExpression") function should work fine, if we define a "pure" function to be something like: > > > 1) Doesn't mutate anything outside its own scope > > > 2) Doesn't call anything involving rand() or other non-deterministic functions > > > 3) Doesn't have a result that depends on the host or target architectures (I'm not sure if this extends to FP subtleties) > > > 4) Doesn't reference any non-local variables which don't themselves have a value that's either itself a literal or the result of evaluating a "pure" function > > > 5) Doesn't call any other functions which aren't themselves "pure", or instantiate any variables using inits that aren't "pure" > > > > > > Since there's already a Swift REPL, at least conceptually speaking, this doesn't seem too hard (although it does raise the bar a bit for what it takes to have a "full" Swift compiler, since it'd then depend on having a working REPL on the host platform, which IIRC wasn't the case on Linux for a while... dunno, maybe this is a non-issue). > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [December 18, 2016, 5:18am UTC](https://forums.swift.org/t/url-literals/4728/38 "2016-12-18T05:18:20Z")
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, preserving the existing API as exactly as possible with no additions or subtractions, and only then to consider Swifty evolution of the APIs. I don't think the first step is complete yet. > **···** > > On Sat, Dec 17, 2016 at 21:46 Step C via swift-evolution \< swift-evolution@swift.org\> wrote: > > > 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 \< \> swift-evolution@swift.org\> wrote: > > \> > > \> 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, David Sweeris \ wrote: > > \>\>\> > > \>\>\> > > \>\>\> > > \>\>\> Sent from my iPhone > > \>\>\> > > \>\>\>\> On Dec 17, 2016, at 13:12, Micah Hainline via swift-evolution \< \> swift-evolution@swift.org\> 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 that shows > > how I'd envision it working. > > \>\> > > \>\> Oh, and to be clear, I'm not trying to "claim" this or anything... if > > anyone else has ideas, please post them! The more the merrier. > > \> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > \> swift-evolution mailing list > > \> swift-evolution@swift.org > > \> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Benjamin\_Spratling](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benjamin_spratling/32/2488_2.png) [@Benjamin\_Spratling](https://forums.swift.org/u/Benjamin_Spratling)\ **Post date:** [December 19, 2016, 8:26am UTC](https://forums.swift.org/t/url-literals/4728/39 "2016-12-19T08:26:45Z")
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 validated by this method? If it really is just URL’s, then I’d actually lean towards making this a compiler magic feature.   Someone else mentioned fetching the URL’s for a preview. Given that we might be coding “deletes” in URL’s (yes, I recently met a backend developer who coded a delete as a GET), I really highly suggest we not ping people’s API’s artificially. At least we shouldn’t for non-file-scheme URLs. IMHO, verifying that a service is active isn’t really the Swift compiler’s job. It might happen as part of coordinated run-time tests, which sometimes have to be balanced to keep test data correct, something the IDE wouldn’t know how to enforce correctly. -Ben > **···** > > > On Dec 19, 2016, at 1:41 AM, David Sweeris via swift-evolution \ wrote: > > > > > 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 thinking something like this (which has been very simplified on account of my regexing being sub-sketchy, and me not knowing exactly what’s valid in an URL anyway): > > #literalpatterns += (name: “URLLiteralType”, components: (name: url, type: StringLiteralType, pattern: “(http|https)://(www.)?[a-z|A-Z|0-9]+.(com|org|net)(/[a-z|A-Z|0-9]+)\*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”), protocol: ExpressibleByURLLiteral) > > This would let the compiler know pretty much everything it needs to know… that the “new” type is called “URLLiteralType", that it starts out life as young StringLiteralType with a bright future in the computer industry, that in order to succeed it has to match a given pattern, and what protocol a type has to conform to in order to use an URLLiteral. In practice, the compiler would synthesize a struct containing the specified members and validate the literal with the specified pattern before making an “instance” of it (since we’re talking about literals and compile-time code here, I’m pretty sure that “instance" the wrong terminology… pardon my ignorance) > > struct URLLiteralType: { > >     let url: StringLiteralType > > } > > A tuple would be better, IMHO, but according to the playground, single-element tuples can’t have element labels. As for the implementation of the init function: > > init(urlLiteral value: URLLiteralType) { > >     let urlString = value.url > >     //Do whatever URL is doing now, except there’s no need to check for errors since the compiler pre-validated it for us > > } > > > > If it’d be more useful, the pattern could be split into multiple pieces: > > #literalpatterns += (name: “URLLiteralType”, > >                      components: ((name: “`protocol`", type: StringLiteralType, pattern: “(http|https)”), > >                                   (name: \_, type: StringLiteralType, pattern: “://”), > >                                   (name: “domain", type: StringLiteralType, pattern: “(www.)?[a-z|A-Z|0-9]+.(com|org|net)”), > >                                   (name: “path”, type: StringLiteralType, pattern: "(/[a-z|A-Z|0-9]+)\*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”)) > >                      protocol: ExpressibleByURLLiteral) > > This would result in URLLiteralType looking like this: > > struct URLLiteralType: { > >     let `protocol`: StringLiteralType > >     let domain: StringLiteralType > >     let path: StringLiteralType > > } > > And in the init would start out like this: > > init(urlLiteral value: URLLiteralType) { > >     let protocolType = value.protocol > >     let domain = value.domain > >     let path = value.path > >     //Do whatever with the components > > } > > > > The “base” types of literals like Int or String that don’t refine pre-existing literal types would still need a bit of compiler magic (or at least a different mechanism for becoming actual types), but as long as a type doesn’t take advantage of reference semantics in its stored properties or something, I \*think\* pretty much any data type could become “literalizeable” with something like this. Oh, and there’s nothing particularly magical about regular expressions as far as this idea is concerned; they’re just usually the first thing that comes to mind when I think of pattern matching in a string. > > > > I know this looks like a lot of code, but the scary-looking parts with the regex stuff only has to be written once for each “type” of literal… types that want to be expressible by such a literal just have to write an init function. > > > > While I was writing this up, it occurred to me that another solution would be to have a set of "ExpressibleByValidated\*Literal” protocols, where the init is failable and has to be @pure/@constexpr/@whateverthecompilerneedstorunitatcompiletime. That way the literal can be validated simply by calling the init and checking if it returns nil. Make `URL` conform to `ExpressibleByValidatedStringLiteral`, and you'll get the complie-time validation functionality just by copying whatever’s in the current `URL.init?(string: String)` function. > > > > - Dave Sweeris > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Rien](https://avatars.discourse-cdn.com/v4/letter/r/0ea827/32.png) [@Rien](https://forums.swift.org/u/Rien)\ **Post date:** [December 19, 2016, 8:09am UTC](https://forums.swift.org/t/url-literals/4728/40 "2016-12-19T08:09:12Z")
I like where this is going! +1 Regards, Rien Site: [http://balancingrock.nl](http://balancingrock.nl) Blog: [http://swiftrien.blogspot.com](http://swiftrien.blogspot.com) Github: [Swiftrien (Rien) · GitHub](http://github.com/Swiftrien) Project: [http://swiftfire.nl](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 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 thinking something like this (which has been very simplified on account of my regexing being sub-sketchy, and me not knowing exactly what’s valid in an URL anyway): > > #literalpatterns += (name: “URLLiteralType”, components: (name: url, type: StringLiteralType, pattern: “(http|https)://(www.)?[a-z|A-Z|0-9]+.(com|org|net)(/[a-z|A-Z|0-9]+)\*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”), protocol: ExpressibleByURLLiteral) > > This would let the compiler know pretty much everything it needs to know… that the “new” type is called “URLLiteralType", that it starts out life as young StringLiteralType with a bright future in the computer industry, that in order to succeed it has to match a given pattern, and what protocol a type has to conform to in order to use an URLLiteral. In practice, the compiler would synthesize a struct containing the specified members and validate the literal with the specified pattern before making an “instance” of it (since we’re talking about literals and compile-time code here, I’m pretty sure that “instance" the wrong terminology… pardon my ignorance) > > struct URLLiteralType: { > >     let url: StringLiteralType > > } > > A tuple would be better, IMHO, but according to the playground, single-element tuples can’t have element labels. As for the implementation of the init function: > > init(urlLiteral value: URLLiteralType) { > >     let urlString = value.url > >     //Do whatever URL is doing now, except there’s no need to check for errors since the compiler pre-validated it for us > > } > > > > If it’d be more useful, the pattern could be split into multiple pieces: > > #literalpatterns += (name: “URLLiteralType”, > >                      components: ((name: “`protocol`", type: StringLiteralType, pattern: “(http|https)”), > >                                   (name: \_, type: StringLiteralType, pattern: “://”), > >                                   (name: “domain", type: StringLiteralType, pattern: “(www.)?[a-z|A-Z|0-9]+.(com|org|net)”), > >                                   (name: “path”, type: StringLiteralType, pattern: "(/[a-z|A-Z|0-9]+)\*(/[a-z|A-Z|0-9]+.[a-z|A-Z|0-9]+)?”)) > >                      protocol: ExpressibleByURLLiteral) > > This would result in URLLiteralType looking like this: > > struct URLLiteralType: { > >     let `protocol`: StringLiteralType > >     let domain: StringLiteralType > >     let path: StringLiteralType > > } > > And in the init would start out like this: > > init(urlLiteral value: URLLiteralType) { > >     let protocolType = value.protocol > >     let domain = value.domain > >     let path = value.path > >     //Do whatever with the components > > } > > > > The “base” types of literals like Int or String that don’t refine pre-existing literal types would still need a bit of compiler magic (or at least a different mechanism for becoming actual types), but as long as a type doesn’t take advantage of reference semantics in its stored properties or something, I \*think\* pretty much any data type could become “literalizeable” with something like this. Oh, and there’s nothing particularly magical about regular expressions as far as this idea is concerned; they’re just usually the first thing that comes to mind when I think of pattern matching in a string. > > > > I know this looks like a lot of code, but the scary-looking parts with the regex stuff only has to be written once for each “type” of literal… types that want to be expressible by such a literal just have to write an init function. > > > > While I was writing this up, it occurred to me that another solution would be to have a set of "ExpressibleByValidated\*Literal” protocols, where the init is failable and has to be @pure/@constexpr/@whateverthecompilerneedstorunitatcompiletime. That way the literal can be validated simply by calling the init and checking if it returns nil. Make `URL` conform to `ExpressibleByValidatedStringLiteral`, and you'll get the complie-time validation functionality just by copying whatever’s in the current `URL.init?(string: String)` function. > > > > - Dave Sweeris > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Previous page](https://forums.swift.org/t/url-literals/4728.md?page=1) [Next page](https://forums.swift.org/t/url-literals/4728.md?page=3)