<div dir="ltr">I think a future release is prudent, for the following reasons:<br><br>1. swift-corelibs-xctest requires users to list each of their tests in an `allTests` static property. However, this isn't source-incompatible with Darwin XCTest. A developer could include the list on Darwin, and their tests would still compile and run just fine.<br>2. We decided back in May that [this feature should be implemented by using SourceKit](<a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160502/001940.html">https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160502/001940.html</a>). Although while SourceKit can technically now be compiled for Linux, it has a dependency upon libdispatch. To build it, we need to refactor the build system to (1) first build the Swift compiler and stdlib, (2) then build libdispatch, (3) finally build SourceKit. I'm not certain that can be done by August 18th (although I'd love to hear from anyone who disagrees!).<div><div>3. Even if we were able to complete step (2), we'd still have to integrate that feature into swift-corelibs-xctest and SwiftPM, which will no doubt take some additional time.</div></div><div><br></div><div>Still, I'm looking forward to this being shipped this in Swift 3.x!</div><div><br></div><div>- Brian Gesiak</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 3:41 PM, Tony Parker <span dir="ltr"><<a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</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">Hm, I’ll have to defer to Mike on the status of this one.<div><br></div><div>If it’s not in place now, we should probably schedule it for a future release.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Tony</div></font></span><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Jul 29, 2016, at 11:43 AM, Brian Gesiak <<a href="mailto:modocache@gmail.com" target="_blank">modocache@gmail.com</a>> wrote:</div><br><div><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" target="_blank">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><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" 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></blockquote></div><br></div>