Hm, I’ll have to defer to Mike on the status of this one. If it’s not in place now, we should probably schedule it for a future release.
- Tony > On Jul 29, 2016, at 11:43 AM, Brian Gesiak <modoca...@gmail.com> wrote: > > Thanks for the heads up, Tony! > > (+cc corelibs-xctest release manager Mike Ferris) > Just to confirm, we are not resolving https://bugs.swift.org/browse/SR-710 > <https://bugs.swift.org/browse/SR-710>, "Generate XCTestCaseProvider entries > on Linux", in time for the Swift 3 release. Is this correct? > > - Brian Gesiak > > > On Fri, Jul 29, 2016 at 2:29 PM, Tony Parker via swift-corelibs-dev > <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: > Hi Gonzalo, > > While not a complete solution for the issues around bridging, the work on > id-as-Any that I mentioned below was meant to help address these platform > differences. > > For example, let’s say you had a Foundation API that looked like this in ObjC: > > - (void)foo:(id)x; > > and imported like this into Swift: > > func foo(_ x : AnyObject) > > On Linux, attempting to call this: > > bar.foo(“hello”) > > would result in an error, because String is not an object type. On Darwin, > String was implicitly bridged to NSString here for you. > > Now (hopefully — I’m still working on verifying this), the above is imported > like this: > > func foo(_ x : Any) > > which means that on Linux, this should actually work: > > bar.foo(“hello”) > > because String is indeed an Any. No need to do something like > “hello”.bridge(). > > AnyHashable also helps. because we should be able to express API which takes > untyped dictionaries with AnyHashable keys instead of NSObject keys. > > Most of this stuff has only landed in the last week or two, so if you can > give it a try and let us know how well it works out, that would be great. > > - Tony > > https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md> > https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md> > > >> On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde <gonzalolarra...@gmail.com >> <mailto:gonzalolarra...@gmail.com>> wrote: >> >> Hi everyone, >> >> Wanted to know if there's any plan to find a solution for Auto Bridging >> between corelibs-foundation <> Swift types in the same manner as it is done >> for Obj-C. >> >> There has been some discussions about this in the following PRs: >> >> https://github.com/apple/swift-corelibs-foundation/pull/310 >> <https://github.com/apple/swift-corelibs-foundation/pull/310> >> https://github.com/apple/swift-corelibs-foundation/pull/303 >> <https://github.com/apple/swift-corelibs-foundation/pull/303> >> https://github.com/apple/swift/pull/1994 >> <https://github.com/apple/swift/pull/1994> >> >> The inclusion of this feature will allow more non-UIKit related packages to >> be used with almost no changes. >> >> For what I understand the main blocker here is getting this to pass through >> Swift review (probably a more generic version of it, like _BridgeableType >> instead of _ObjectiveCBridgeable would help?), but wanted to understand >> first if this is a priority for the foundation team, and there is something >> that can be done to push for this feature. >> >> Thanks! >> >> >> -- >> Slds, >> >> Gonzalo. >> >> On Thu, Jul 28, 2016 at 6:22 PM, Matt Wright via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> The overlay changes were merged to corelibs libdispatch this morning. >> >> Sent from my iPhone. >> >> On Jul 28, 2016, at 2:03 PM, Tony Parker via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> >>> Hi Dave, >>> >>> I don’t believe anyone is looking into this. If you want to do that, I >>> think now would be the time! >>> >>> - Tony >>> >>>> On Jul 28, 2016, at 10:50 AM, David P Grove via swift-corelibs-dev >>>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >>>> >>>> Tony Parker wrote on 07/28/2016 01:41:55 PM: >>>> > >>>> > 1. Integrate swift-corelibs-dispatch into Foundation. >>>> >>>> Hi Tony, >>>> >>>> Hopefully this is on the task list already, but if it isn't we should add >>>> it before it gets to be too late to change the compiler... >>>> >>>> When compiling a Swift program on Linux that imports Dispatch (or >>>> Foundation once the integration is done), the user has to give the extra >>>> compilation flags -Xcc -fblocks to enable block support. >>>> >>>> We really need to land a change somewhere so that either (1) blocks >>>> support is always on for Linux or (2) importing Dispatch or Foundation >>>> automatically turns on blocks support. >>>> >>>> I have some time today and tomorrow that I could use to work on this if no >>>> one is handling it already, but I'm not sure how best to tackle the >>>> problem. Suggestions? >>>> >>>> --dave >>>> >>>> _______________________________________________ >>>> swift-corelibs-dev mailing list >>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >>> >>> _______________________________________________ >>> swift-corelibs-dev mailing list >>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >> >> > > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> > >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
