[swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

[Jacob Bandes-Storch]

If you were to design this API for Swift in the first place, you might want
to do something entirely different:

extension URL {
    enum Reachability {
        case reachable
        case notReachable(ErrorProtocol)
    }
    func reachability() -> Reachability
}

On Sun, Aug 7, 2016 at 12:20 PM, Félix Cloutier <swift-evolution at swift.org>
wrote:

> I read it from the Mac Developer Library's documentation, which has all of
> that for the Swift version too (link
> <https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSURL_Class/#//apple_ref/occ/instm/NSURL/checkResourceIsReachableAndReturnError:>
> ).
>
> I was commenting on the awkwardness of the Objective-C interface. Given
> that the error parameter is only populated when the return value is
> `false`, in the transposed Swift world, you shouldn't need to check the
> return value.
>
> Félix
>
> Le 7 août 2016 à 12:14:38, Charles Srstka <cocoadev at charlessoft.com> a
> écrit :
>
> On Aug 7, 2016, at 1:59 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>
>
> One line above the text that you quoted, you can read:
>
> If this method returns false, the object pointer referenced by error is
> populated with additional information.
>
>
> That’s only in the documentation for the original NSURL method (which
> still returns an error by reference). This is the entirety of the
> description in the documentation for the new one on URL:
>
> "This method synchronously checks if the resource’s backing store is
> reachable. Checking reachability is appropriate when making decisions that
> do not require other immediate operations on the resource, e.g. periodic
> maintenance of UI state that depends on the existence of a specific
> document. When performing operations such as opening a file or copying
> resource properties, it is more efficient to simply try the operation and
> handle failures. This method is currently applicable only to URLs for file
> system resources. For other URL types, false is returned.”
>
> The rationale is probably that this method was awkward to begin with. It's
> unclear to me why it was decided to return a `NSError` by reference and a
> bool that is seemingly equivalent to `error != nil`.
>
>
> It’s not like that anymore. On the new URL value type, it both returns a
> bool *and* is marked ‘throws’. So you have to check *both* whether it
> returned false *and* whether it threw an error.
>
> Charles
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160807/49adab8e/attachment.html>