Wrapping up Swift 3 for swift-corelibs

Development Core Libraries
1

Hi everyone,

We’re getting close to the finish line for Swift 3, but we still have some work to do in swift-corelibs, especially swift-corelibs-foundation. I want to lay out what our goals and plans are for the next few weeks.

As Swift 3 has been wrapping up, an immense number of important syntax and language changes have landed which have rendered many of our source-compatibility efforts for swift-corelibs-foundation obsolete. The most important is id-as-Any (https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md\). As this affects how all Objective-C API is imported, and a lot of Foundation’s API comes from Objective-C, many of our APIs have changed (for the better). There have also been constant refinements and improvements to many of the Foundation value types, and their effect on Foundation API.

Therefore, we are extending the deadline for swift-corelibs-foundation API changes for another 3 weeks (Aug 18), so that we can land three critical tasks:

1. Integrate swift-corelibs-dispatch into Foundation.
2. Land the URLSession implementation (https://github.com/apple/swift-corelibs-foundation/pull/426\)
3. Update our API to match the final APIs shipped in Swift 3 for Darwin

At this time we are going to focus on just these goals. Additional implementations will have to wait until the next release (which we will start planning soon, along with the rest of the Swift 4 efforts).

I want to thank everyone for their hard work on the core libraries so far. We’ve accomplished an amazing amount in such a short time! Now, if we can wrap up these three things, we will be in great shape for our first official release.

- Tony

2

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

3

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

···

Tony Parker wrote on 07/28/2016 01:41:55 PM:

1. Integrate swift-corelibs-dispatch into Foundation.

4

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

5

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 <daniel.j.stenmark@gmail.com> wrote:

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

6

I had a quick conversation with Daniel Dunbar on this. Adding -Xcc
-fblocks as a default option to Swift PM (on Linux). The wrinkle is the
availability of the blocks runtime - it would either need to become a
pre-req for Swift, or needs one to be built into the package.

Chris

<swift-corelibs-dev@swift.org>

···

From: David P Grove via swift-corelibs-dev
To: Swift corelibs dev <swift-corelibs-dev@swift.org>
Date: 28/07/2016 18:50
Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for
swift-corelibs
Sent by: swift-corelibs-dev-bounces@swift.org

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

7

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

8

Can someone file a bug to track how we are going to resolve this issue, and outline our options? I want to make sure we have enough eyes on it to make sure we get what we need for Swift 3.

- Daniel

···

On Aug 1, 2016, at 3:08 AM, Chris Bailey <BAILEYC@uk.ibm.com> wrote:

I had a quick conversation with Daniel Dunbar on this. Adding -Xcc -fblocks as a default option to Swift PM (on Linux). The wrinkle is the availability of the blocks runtime - it would either need 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 <swift-corelibs-dev@swift.org>
Date: 28/07/2016 18:50
Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for swift-corelibs
Sent by: swift-corelibs-dev-bounces@swift.org

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

9

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:

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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

10

Speaking of JIRA tasks, I remembered this morning that the versions of
swift-corelibs-foundation and swift-corelibs-xctest expose public API that
does not exist in their Apple counterparts. This is because of a bug in the
linker that prevents us from marking attributes as private:

- [SR-1129] Linker step fails when subclassing a class with a 'public private(set) var' · Issue #395 · apple/swift-corelibs-xctest · GitHub
- [SR-1901] Linker error "hidden symbol" on subclassing Thread · Issue #4133 · apple/swift-corelibs-foundation · GitHub

It would be great if we could fix this problem prior to the Swift 3
release, but if not, we need to be aware that some people may end up using
or relying upon these "unintentionally public" API.

- Brian Gesiak

···

On Wed, Aug 3, 2016 at 2:10 PM, Daniel Dunbar via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote:

Can someone file a bug to track how we are going to resolve this issue,
and outline our options? I want to make sure we have enough eyes on it to
make sure we get what we need for Swift 3.

- Daniel

On Aug 1, 2016, at 3:08 AM, Chris Bailey <BAILEYC@uk.ibm.com> wrote:

I had a quick conversation with Daniel Dunbar on this. Adding -Xcc
-fblocks as a default option to Swift PM (on Linux). The wrinkle is the
availability of the blocks runtime - it would either need 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 <swift-corelibs-dev@swift.org>
Date: 28/07/2016 18:50
Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for
swift-corelibs
Sent by: swift-corelibs-dev-bounces@swift.org
------------------------------

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

11

Bug filed: [SR-2309] Linux: libdispatch runtime dependency on blocks runtime · Issue #726 · apple/swift-corelibs-libdispatch · GitHub

I've prototyped potential solution #2 this morning (embedding yet another
copy of the blocks runtime into libdispatch). I need to do a little
cleanup of the build plumbing, but it is workable.

I have time to work on it this week once there is a consensus on the
approach.

--dave

···

From: Daniel Dunbar <daniel_dunbar@apple.com>
To: Chris Bailey <BAILEYC@uk.ibm.com>
Cc: David P Grove/Watson/IBM@IBMUS, "swift-corelibs-dev@swift.org"
            <swift-corelibs-dev@swift.org>
Date: 08/03/2016 02:10 PM
Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for swift-corelibs
Sent by: daniel_dunbar@apple.com

Can someone file a bug to track how we are going to resolve this issue, and
outline our options? I want to make sure we have enough eyes on it to make
sure we get what we need for Swift 3.

- Daniel

      On Aug 1, 2016, at 3:08 AM, Chris Bailey <BAILEYC@uk.ibm.com> wrote:

      I had a quick conversation with Daniel Dunbar on this. Adding -Xcc
      -fblocks as a default option to Swift PM (on Linux). The wrinkle is
      the availability of the blocks runtime - it would either need 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 <swift-corelibs-dev@swift.org>
      Date: 28/07/2016 18:50
      Subject: Re: [swift-corelibs-dev] Wrapping up Swift 3 for
      swift-corelibs
      Sent by: swift-corelibs-dev-bounces@swift.org

      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@swift.org
      https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

12

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

···

On Jul 29, 2016, at 11:06 AM, Gonzalo Larralde <gonzalolarralde@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:

Replace all bridge() calls with corresponding as expression in test cases by dgrove-oss · Pull Request #310 · apple/swift-corelibs-foundation · GitHub
Basic usage of ObjectiveCBridgeable protocol on Linux by dgrove-oss · Pull Request #303 · apple/swift-corelibs-foundation · GitHub
Enablement of ObjectiveCBridgeable protocol for Linux by dgrove-oss · Pull Request #1994 · apple/swift · GitHub

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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

13

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@gmail.com> wrote:

Thanks for the heads up, Tony!

(+cc corelibs-xctest release manager Mike Ferris)
Just to confirm, we are not resolving [SR-710] Generate XCTestCaseProvider entries on Linux · Issue #5320 · apple/swift-package-manager · GitHub, "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@swift.org <mailto:swift-corelibs-dev@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@gmail.com <mailto:gonzalolarralde@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:

Replace all bridge() calls with corresponding as expression in test cases by dgrove-oss · Pull Request #310 · apple/swift-corelibs-foundation · GitHub
Basic usage of ObjectiveCBridgeable protocol on Linux by dgrove-oss · Pull Request #303 · apple/swift-corelibs-foundation · GitHub
Enablement of ObjectiveCBridgeable protocol for Linux by dgrove-oss · Pull Request #1994 · apple/swift · GitHub

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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@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@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

14

Thanks for the heads up, Tony!

(+cc corelibs-xctest release manager Mike Ferris)
Just to confirm, we are not resolving [SR-710] Generate XCTestCaseProvider entries on Linux · Issue #5320 · apple/swift-package-manager · GitHub,
"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@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@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:

Replace all bridge() calls with corresponding as expression in test cases by dgrove-oss · Pull Request #310 · apple/swift-corelibs-foundation · GitHub
Basic usage of ObjectiveCBridgeable protocol on Linux by dgrove-oss · Pull Request #303 · apple/swift-corelibs-foundation · GitHub
Enablement of ObjectiveCBridgeable protocol for Linux by dgrove-oss · Pull Request #1994 · apple/swift · GitHub

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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

15

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 still compile and run just fine.
2. We decided back in May that [this feature should be implemented by using
SourceKit](
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160502/001940.html\).
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!).
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.

Still, I'm looking forward to this being shipped this in Swift 3.x!

- Brian Gesiak

···

On Fri, Jul 29, 2016 at 3:41 PM, Tony Parker <anthony.parker@apple.com> wrote:

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@gmail.com> wrote:

Thanks for the heads up, Tony!

(+cc corelibs-xctest release manager Mike Ferris)
Just to confirm, we are not resolving [SR-710] Generate XCTestCaseProvider entries on Linux · Issue #5320 · apple/swift-package-manager · GitHub,
"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@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@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:

Replace all bridge() calls with corresponding as expression in test cases by dgrove-oss · Pull Request #310 · apple/swift-corelibs-foundation · GitHub
Basic usage of ObjectiveCBridgeable protocol on Linux by dgrove-oss · Pull Request #303 · apple/swift-corelibs-foundation · GitHub
Enablement of ObjectiveCBridgeable protocol for Linux by dgrove-oss · Pull Request #1994 · apple/swift · GitHub

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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev