[swift-corelibs-dev] Wrapping up Swift 3 for swift-corelibs

[Tony Parker]

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 <modocache at 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 at swift.org <mailto:swift-corelibs-dev at 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 <gonzalolarralde at gmail.com <mailto:gonzalolarralde at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160729/bd94c720/attachment.html>