Noted, but again while force-unwrapping it is the best we have, compile-time checking would be even better.
> On Dec 16, 2016, at 7:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline <micah.hainl...@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/";)!` 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 <xiaodi...@gmail.com> 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 <wh1pch...@gmail.com> 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 >>>>>> <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 >>>>>> > <char...@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";)! >>>>>> >>> >>>>>> >>> 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 >>>>>> >>> swift-evolution@swift.org >>>>>> >>> 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 >>>>>> > >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
