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

[Brian Gesiak]

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