<div dir="ltr">On Mon, Dec 19, 2016 at 1:55 AM, Benjamin Spratling <span dir="ltr"><<a href="mailto:bspratling@mac.com" target="_blank">bspratling@mac.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Howdy,</div><div id="m_1044240693457261912AppleMailSignature"> 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.</div><div id="m_1044240693457261912AppleMailSignature"><br></div><div id="m_1044240693457261912AppleMailSignature">I have seen some good developers "think" they "know" the value can't be nil, and they were just wrong.</div></div></blockquote><div><br></div><div>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:</div><div><br></div><div>```</div><div>guard let foo = bar else {</div><div> fatalError() // Bye.</div><div>}</div><div>```</div><div><br></div><div>In those cases, it is perfectly legitimate to write:</div><div><br></div><div>```</div><div>let foo = bar!</div><div>```</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div id="m_1044240693457261912AppleMailSignature">But when we can specifically run a unit test with 0 inputs on the value, then falsification of nullability is easy.<br><br>-Ben<div><br>Sent from my iPhone.</div></div><div><div class="h5"><div><br>On Dec 16, 2016, at 7:30 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline <span dir="ltr"><<a href="mailto:micah.hainline@gmail.com" target="_blank">micah.hainline@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div></div><div>It's not super strong, but it's as strong as the URL type itself. </div><div><br></div><div>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><br></div><div>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><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>It does help to have one of them accounted for by the compiler if possible.</div><div><br></div><div>I'm trying to teach some less experienced developers to think of force-unwrapping as a code smell,</div></div></blockquote><div><br></div><div>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><br></div><div>It should be noted that `let url = URL(string: "<a href="http://example.com/" 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><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>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><div class="m_1044240693457261912gmail-h5"><div><br>On Dec 16, 2016, at 6:45 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div></div><div>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><br></div><div>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><br></div><div>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><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div><div class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708h5"><div>On Dec 16, 2016, at 5:50 PM, Derrick Ho <<a href="mailto:wh1pch81n@gmail.com" target="_blank">wh1pch81n@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div>let url = URL(string: "<a href="https://example.com" target="_blank">https://example.com</a>")!<br><br>let url = #url("<a href="https://example.com" target="_blank">https://example.com</a>")<br><br>Are not that different in length. It really isn't saving you much.<br><br>I suppose you can try overloading an operator to get something to the effect you want.<br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Exactly! It's not an earth-shattering pain, but it would be nice to have clean type safety there.<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
> On Dec 16, 2016, at 4:01 PM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">charlie@charliemonroe.net</a>> wrote:<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> I would like to be able to create a URL literal that is compile-time<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> checked for correct format. This would help avoid code like this:<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> let url: URL = URL(string: "<a href="https://example.com" rel="noreferrer" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://example.com</a>")!<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> The cleanest way I can think of doing that would be to introduce a new<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> macro structure similar to #selector, though I'm open to other ideas.<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> I would think it should take a quoted literal string to avoid<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> problems. That would look like this:<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> let url: URL = #url("<a href="https://example.com" rel="noreferrer" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://example.com</a>")<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> What does everyone think of that idea?<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> ______________________________<wbr>_________________<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> swift-evolution mailing list<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> <a href="mailto:swift-evolution@swift.org" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>> I’d like to see something like that for file path URLs. For something so commonly used, URL(fileURLWithPath:) is obnoxiously verbose.<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>> Charles<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
> 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="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>> ______________________________<wbr>_________________<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>> swift-evolution mailing list<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>> <a href="mailto:swift-evolution@swift.org" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
______________________________<wbr>_________________<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
swift-evolution mailing list<br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br class="m_1044240693457261912gmail-m_5097139748465069364m_-7437690872945372708m_5158479000790778923gmail_msg">
</blockquote></div>
</div></blockquote></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div></div>