re is a consensus on the
approach.
--dave
From: Daniel Dunbar
To: Chris Bailey
Cc: David P Grove/Watson/IBM@IBMUS, "swift-corelibs-dev@swift.org"
Date: 08/03/2016 02:10 PM
Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for swift-c
eed to become a
> pre-req for Swift, or needs one to be built into the package.
>
> Chris
>
>
>
>
> From:David P Grove via swift-corelibs-dev <
> swift-corelibs-dev@swift.org>
> To: Swift corelibs dev
> Date: 28/07/2016 18:50
>
t;
> From:David P Grove via swift-corelibs-dev
>
> To:Swift corelibs dev
> Date: 28/07/2016 18:50
> Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for
> swift-corelibs
> Sent by:swift-corelibs-dev-boun...@swift.org
>
>
P Grove via swift-corelibs-dev
To: Swift corelibs dev
Date: 28/07/2016 18:50
Subject:Re: [swift-corelibs-dev] Wrapping up Swift 3 for
swift-corelibs
Sent by:swift-corelibs-dev-boun...@swift.org
Tony Parker wrote on 07/28/2016 01:41:55 PM:
>
> 1. Integrate
I think a future release is prudent, for the following reasons:
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 stil
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 wrote:
>
> Thanks for the heads up, Tony!
>
> (+cc corelibs-xctest release manager Mike Ferris)
> Just t
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
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
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
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
> 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!
>
> -
Hi Dan,
I believe Matt is working on getting the remaining overlay changes into Linux
as we speak.
- Tony
> On Jul 28, 2016, at 10:48 AM, Dan Stenmark
> wrote:
>
>> 1. Integrate swift-corelibs-dispatch into Foundation.
>
> Are there any lingering items in swift-corelibs-dispatch that are st
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
> wrote:
>
> Tony Parker wrote on 07/28/2016 01:41:55 PM:
> >
> > 1. Integrate swift-corelibs-dispatch int
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
> 1. Integrate swift-corelibs-dispatch into Foundation.
Are there any lingering items in swift-corelibs-dispatch that are still pending
full implementations on either Darwin or Linux?
Dan
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
14 matches
Mail list logo
