Hm, I’ll have to defer to Mike on the status of this one.
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