Hi Zach, Daniel,
> On Mar 31, 2016, at 11:03 AM, Zach Waldowski via swift-corelibs-dev
> wrote:
>
> The semantics of the methods are fairly nuanced in ObjC.
>
> You can have a resource value that fails to be fetched, or one that
> succeeded to fetch but had no value. A Swift version would mode
The semantics of the methods are fairly nuanced in ObjC.
You can have a resource value that fails to be fetched, or one that
succeeded to fetch but had no value. A Swift version would model this as
`throws -> AnyObject?`.
For the dictionary version, you may ask for a resource value, it
succeeds,
Well, there's
func resourceValuesForKeys(_ keys: [String]) throws -> [String : AnyObject]
which doesn't use AutoreleasingUnsafeMutablePointer, but that doesn't exist in
Swift, either.
And the other one could have a replacement like so:
func resourceValue(forKey key: String) -> AnyObject throws
You can't have AutoreleasingUnsafeMutablePointer without Objective-C
interop.
Zach
On Thu, Mar 31, 2016, at 07:17 AM, Daniel Eggert via swift-corelibs-dev
wrote:
> What's the reason for the "resource value" API on NSURL not being present
> in SwiftFoundation?
>
> /Daniel
>
>
> func getResource
Is there interest in bridging between dispatch_data_t and NSData similar to
what's available with Darwin Foundation. Being able to avoid buffer copies
seems like a big win. And with libdispatch (almost) being available on Linux,
would it make sense to back (immutable) NSData with libdispatch in
What's the reason for the "resource value" API on NSURL not being present in
SwiftFoundation?
/Daniel
func getResourceValue(_ value: AutoreleasingUnsafeMutablePointer,
forKey key: String) throws
___
swift-corelibs-dev mailing list
swift-corelibs-dev
