<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1. Tony’s static evaluation idea also crossed my mind when reading this thread.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2016, at 10:52 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">If folks want to go down this path, it:</div><div class=""><br class=""></div><div class="">* shouldn't require compiler magic</div><div class="">* shouldn't be restricted to specific types</div><div class="">* should be something that anyone can take advantage of in types that they write.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Quick back of the napkin sketch, I haven't thought too much about syntax details yet:</div><div class=""><br class=""></div><div class="">struct URL: ExpressibleByStringLiteral {</div><div class=""> // the #, or something similar, indicates this</div><div class=""> // is compile-time evaluation</div><div class=""> #init?(_ stringLiteral: StaticString) {</div><div class=""> // validate the string. We'd be able to use</div><div class=""> // loops and access individual characters</div><div class=""> // in the static string... regexes would be</div><div class=""> // trickier.</div><div class=""> if valid {</div><div class=""> // if we get here, everything we did</div><div class=""> // will essentially "collapse" to this</div><div class=""> // initializer call in the generated code</div><div class=""> self.init(...)!</div><div class=""> } else {</div><div class=""> return nil</div><div class=""> // need a way of emitting a more</div><div class=""> // informational error message?</div><div class=""> }</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""><div class="gmail_quote"><div class="">On Sat, Dec 17, 2016 at 5:57 AM Step C via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">Do you have a treatment in mind? </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Perhaps the compiler recognizes types/initializers it can check at compile time (how?). Then it could synthesize non-failable initializers. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.)</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Step</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Dec 16, 2016, at 9:46 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">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".<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Fri, Dec 16, 2016 at 20:33 Micah Hainline <<a href="mailto:micah.hainline@gmail.com" class="gmail_msg" target="_blank">micah.hainline@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On Dec 16, 2016, at 8:14 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Fri, Dec 16, 2016 at 8:00 PM, Micah Hainline <span class="gmail_msg"><<a href="mailto:micah.hainline@gmail.com" class="gmail_msg" target="_blank">micah.hainline@gmail.com</a>></span> wrote:<br class="gmail_msg"></div><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">We'll have to agree to disagree about the value of getting rid of the force-unwrap.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg m_8047034319016590747m_-8822947579576768064h5"><div class="gmail_msg">On Dec 16, 2016, at 7:54 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Fri, Dec 16, 2016 at 7:44 PM, Micah Hainline <span class="gmail_msg"><<a href="mailto:micah.hainline@gmail.com" class="gmail_msg" target="_blank">micah.hainline@gmail.com</a>></span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">Noted, but again while force-unwrapping it is the best we have, compile-time checking would be even better.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What I was trying to point out is that I agree with Derrick that the _spelling_ `URL(string: "<a href="https://example.com/" class="gmail_msg" target="_blank">https://example.com/</a>")!` is perfectly fine and not in need of improvement, and that I disagree strongly that force unwrapping is problematic as a matter of style.</div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-h5"><div class="gmail_msg">On Dec 16, 2016, at 7:30 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline <span class="gmail_msg"><<a href="mailto:micah.hainline@gmail.com" class="gmail_msg" target="_blank">micah.hainline@gmail.com</a>></span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">It's not super strong, but it's as strong as the URL type itself. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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?</div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">It does help to have one of them accounted for by the compiler if possible.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I'm trying to teach some less experienced developers to think of force-unwrapping as a code smell,</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It should be noted that `let url = URL(string: "<a href="http://example.com/" class="gmail_msg" target="_blank">http://example.com/</a>")!` 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.</div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">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. 🙂</div><div class="gmail_msg"><div class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-h5"><div class="gmail_msg"><br class="gmail_msg">On Dec 16, 2016, at 6:45 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution <span class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg">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.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708h5"><div class="gmail_msg">On Dec 16, 2016, at 5:50 PM, Derrick Ho <<a href="mailto:wh1pch81n@gmail.com" class="gmail_msg" target="_blank">wh1pch81n@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">let url = URL(string: "<a href="https://example.com/" class="gmail_msg" target="_blank">https://example.com</a>")!<br class="gmail_msg"><br class="gmail_msg">let url = #url("<a href="https://example.com/" class="gmail_msg" target="_blank">https://example.com</a>")<br class="gmail_msg"><br class="gmail_msg">Are not that different in length. It really isn't saving you much.<br class="gmail_msg"><br class="gmail_msg">I suppose you can try overloading an operator to get something to the effect you want.<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Exactly! It's not an earth-shattering pain, but it would be nice to have clean type safety there.<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class=""><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">> On Dec 16, 2016, at 4:01 PM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">charlie@charliemonroe.net</a>> wrote:<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> I would like to be able to create a URL literal that is compile-time<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> checked for correct format. This would help avoid code like this:<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> let url: URL = URL(string: "<a href="https://example.com/" rel="noreferrer" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://example.com</a>")!<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> The cleanest way I can think of doing that would be to introduce a new<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> macro structure similar to #selector, though I'm open to other ideas.<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> I would think it should take a quoted literal string to avoid<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> problems. That would look like this:<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> let url: URL = #url("<a href="https://example.com/" rel="noreferrer" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://example.com</a>")<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> What does everyone think of that idea?<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> _______________________________________________<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> swift-evolution mailing list<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>> I’d like to see something like that for file path URLs. For something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose.<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>> Charles<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">> 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.<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>> _______________________________________________<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>> swift-evolution mailing list<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">_______________________________________________<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class="">swift-evolution mailing list<br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class=""><a href="mailto:swift-evolution@swift.org" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg m_8047034319016590747m_-8822947579576768064m_7231813643240567837gmail-m_-3633212441428767616gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg"><br class=""><br class=""></blockquote></div><br class=""><br class=""></div></blockquote></div></div></div><br class="gmail_msg">_______________________________________________<br class="gmail_msg"><br class=""><br class="">swift-evolution mailing list<br class="gmail_msg"><br class=""><br class=""><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class=""><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class=""><br class=""><br class="gmail_msg"></blockquote></div><br class="gmail_msg"></div></div><br class=""><br class=""></div></blockquote></div></div></div></blockquote></div><br class="gmail_msg"></div></div><br class=""><br class=""></div></blockquote></div></div></div></blockquote></div><br class="gmail_msg"></div></div><br class=""><br class=""></div></blockquote></div></div></div></blockquote></div><br class="gmail_msg"></div></div><br class=""><br class=""></div></blockquote></div></blockquote></div><br class=""><br class=""></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg"><br class="">swift-evolution mailing list<br class="gmail_msg"><br class=""><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class=""></blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>