<div dir="ltr">Thanks for the heads up, Tony!<div><br>(+cc corelibs-xctest release manager Mike Ferris)</div><div>Just to confirm, we are not resolving <a href="https://bugs.swift.org/browse/SR-710">https://bugs.swift.org/browse/SR-710</a>, "Generate XCTestCaseProvider entries on Linux", in time for the Swift 3 release. Is this correct?<br><br>- Brian Gesiak<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 2:29 PM, Tony Parker via swift-corelibs-dev <span dir="ltr"><<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Gonzalo,<div><br></div><div>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.</div><div><br></div><div>For example, let’s say you had a Foundation API that looked like this in ObjC:</div><div><br></div><div>- (void)foo:(id)x;</div><div><br></div><div>and imported like this into Swift:</div><div><br></div><div>func foo(_ x : AnyObject)</div><div><br></div><div>On Linux, attempting to call this:</div><div><br></div><div>bar.foo(“hello”)</div><div><br></div><div>would result in an error, because String is not an object type. On Darwin, String was implicitly bridged to NSString here for you.</div><div><br></div><div>Now (hopefully — I’m still working on verifying this), the above is imported like this:</div><div><br></div><div>func foo(_ x : Any)</div><div><br></div><div>which means that on Linux, this should actually work:</div><div><br></div><div>bar.foo(“hello”)</div><div><br></div><div>because String is indeed an Any. No need to do something like “hello”.bridge().</div><div><br></div><div>AnyHashable also helps. because we should be able to express API which takes untyped dictionaries with AnyHashable keys instead of NSObject keys.</div><div><br></div><div>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.</div><div><br></div><div>- Tony</div><div><br></div><div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md</a></div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md</a></div><div><br></div></div><div><div class="h5"><div><br></div><div><div><blockquote type="cite"><div>On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde <<a href="mailto:gonzalolarralde@gmail.com" target="_blank">gonzalolarralde@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Hi everyone,<div><br></div><div>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.</div><div><br></div><div>There has been some discussions about this in the following PRs:</div><div><br></div><div><a href="https://github.com/apple/swift-corelibs-foundation/pull/310" target="_blank">https://github.com/apple/swift-corelibs-foundation/pull/310</a><br></div><div><a href="https://github.com/apple/swift-corelibs-foundation/pull/303" target="_blank">https://github.com/apple/swift-corelibs-foundation/pull/303</a><br></div><div><a href="https://github.com/apple/swift/pull/1994" target="_blank">https://github.com/apple/swift/pull/1994</a><br></div><div><br></div><div>The inclusion of this feature will allow more non-UIKit related packages to be used with almost no changes. </div><div><br></div><div>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.</div><div><br></div><div>Thanks!</div></div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature"><br>--<br>Slds,<br><br>Gonzalo.</div></div>
<br><div class="gmail_quote">On Thu, Jul 28, 2016 at 6:22 PM, Matt Wright via swift-corelibs-dev <span dir="ltr"><<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div style="direction:inherit">The overlay changes were merged to corelibs libdispatch this morning. </div><br>Sent from my iPhone.</div><div><div><div><br>On Jul 28, 2016, at 2:03 PM, Tony Parker via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Hi Dave,<div><br></div><div>I don’t believe anyone is looking into this. If you want to do that, I think now would be the time!</div><div><br></div><div>- Tony</div><div><br><div><blockquote type="cite"><div>On Jul 28, 2016, at 10:50 AM, David P Grove via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>> wrote:</div><br><div><div><p><tt>Tony Parker wrote on 07/28/2016 01:41:55 PM:</tt><br><tt>> <br>> 1. Integrate swift-corelibs-dispatch into Foundation.</tt><br><br><tt>Hi Tony,</tt><br><br><tt> 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...</tt><br><br><tt> 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.</tt><br><br><tt> 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.</tt><br><br><tt> 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?</tt><br><br><tt>--dave</tt><br><br>
</p></div>
_______________________________________________<br>swift-corelibs-dev mailing list<br><a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br></div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-corelibs-dev mailing list</span><br><span><a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" target="_blank">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
swift-corelibs-dev mailing list<br>
<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
swift-corelibs-dev mailing list<br>
<a href="mailto:swift-corelibs-dev@swift.org">swift-corelibs-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br>
<br></blockquote></div><br></div>