On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline <[email protected]> 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/";)!` 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 <[email protected]> wrote: > > On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution < > [email protected]> 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 <[email protected]> wrote: >> >> let url = URL(string: "https://example.com";)! >> >> let url = #url("https://example.com";) >> >> Are not that different in length. It really isn't saving you much. >> >> I suppose you can try overloading an operator to get something to the >> effect you want. >> On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift-evolution < >> [email protected]> 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 <[email protected]> >>> wrote: >>> > >>> > >>> >>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution < >>> [email protected]> wrote: >>> >>> >>> >>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution < >>> [email protected]> wrote: >>> >>> >>> >>> I would like to be able to create a URL literal that is compile-time >>> >>> checked for correct format. This would help avoid code like this: >>> >>> >>> >>> let url: URL = URL(string: "https://example.com";)! >>> >>> >>> >>> The cleanest 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";) >>> >>> >>> >>> What does everyone think of that idea? >>> >>> _______________________________________________ >>> >>> swift-evolution mailing list >>> >>> [email protected] >>> >>> 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 >>> >> [email protected] >>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>> > >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
