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 <[email protected]> a écrit : > >> On Aug 7, 2016, at 1:59 PM, Félix Cloutier <[email protected] >> <mailto:[email protected]>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
