I have to agree with your line of thinking, Micah. We've been in the exact same position when it comes to teaching beginners to avoid force unwrapping except URLs.
+1 on this from me! Mark > On Dec 16, 2016, at 19:01, Micah Hainline via swift-evolution > <[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. 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, 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
