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, "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> 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/0131-anyhashable.md > > > On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde <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/303 > 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> 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> 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> 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 >> 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 >> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org >> 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 > >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
