bridging (SR-138)

Drew_Crawford1 · January 2, 2016, 8:24am

I've noticed that e.g. String is not bridged to NSString. The expected workaround seems to be calling .bridge() everywhere.

1. Is there a plan for bridging e.g. String with NSString?
2. Would it be appropriate to PR in the meantime e.g.

extension String {
        public func cStringUsingEncoding(encoding: UInt) -> UnsafePointer<Int8> {
            return self.bridge().cStringUsingEncoding(encoding)
        }
    }

3. The README also says

We will also drop the 'NS' prefix from all Foundation classes

...is that the resolution? e.g what is currently class NSString will become instead extension String? Is there a bug open for that?

keith-other · January 2, 2016, 8:46am

There's a mention of this in the "Issues" document here:

github.com

apple/swift-corelibs-foundation/blob/main/Docs/Issues.md#known-issues

# Known Issues

* We're not yet finished implementing all of the core functionality of Foundation.

* NSDictionary, NSArray, NSSet and NSString are not yet implicitly convertible to Dictionary, Array, Set, and String. In order to translate between these types, we have temporarily added a protocol to these types that allows them to be converted. There is one method called `bridge()`.

```swift
let myArray: NSArray = ["foo", "bar", "baz"].bridge()
```

This also means that functions like map or reduce are currently unavailable on NSDictionary and NSArray.

These limitations should hopefully be very short-term.

A fix in the compiler is needed to split out the concept of "bridgeable to Objective-C" from "bridgeable to AnyObject". In the meantime, we have added the implementation of the `_ObjectiveCBridgeable` protocol to Foundation on Linux (normally it is part of the standard library).

In short: users or implementers should be careful about the implicit conversions that may be inserted automatically by the compiler. Be sure to compile and test changes on both Darwin and Linux.

* The `AutoreleasingUnsafeMutablePointer` type is not available on Linux because it requires autorelease logic provided by the Objective-C runtime. Most often this is not needed, but does create a divergence in some APIs like `NSFormatter` or the funnel methods of NSDictionary, NSArray and others. In these areas, we have proposed new API (marked with `Experiment:`) to work around use of the type. This proposed API is subject to change as the project progresses and should not yet be considered stable.

This file has been truncated. show original

That makes it sound like this isn't meant to be a long term limitation:

In order to translate between these types, we have temporarily added a
protocol to these types that allows them to be converted.

And:

···

These limitations should hopefully be very short-term.

--
Keith Smiley

On 01/02, Drew Crawford via swift-corelibs-dev wrote:

I've noticed that e.g. String is not bridged to NSString. The expected workaround seems to be calling .bridge() everywhere.

1. Is there a plan for bridging e.g. String with NSString?
2. Would it be appropriate to PR in the meantime e.g.

extension String {
        public func cStringUsingEncoding(encoding: UInt) -> UnsafePointer<Int8> {
            return self.bridge().cStringUsingEncoding(encoding)
        }
    }

  3. The README also says

> We will also drop the 'NS' prefix from all Foundation classes

...is that the resolution? e.g what is currently class NSString will become instead extension String? Is there a bug open for that?

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

Philippe_Hausler · January 2, 2016, 8:57am

String is bridged it just is not yet implicitly converted via the compiler; we are missing certain functionality due to the compiler not supporting the objc code paths on linux.

The re-naming of swift classes exposed from Foundation will likely leave the class NSString still a thing (however it likely will have some special case of naming since there is a conflict between Foundation’s String and Swift’s String that is yet to be determined fully on how that will be done), so it is still a bit up-in-the-air on how that will be achieved. However since there are desired behavioral differences between NSString and String we cannot just wholesale make it an extension since some of the functions that apply to NSString don’t make much sense for String (e.g. characterAtIndex etc).

The bug you are probably looking for is: https://bugs.swift.org/browse/SR-138\. Basically what we need is _ObjectTypeBridgeable to behave similarly to the type conversion portion of _ObjectiveCBridgeable. This would likely be primarily work in the compiler and also a bit of work in the stdlib for a few of the overlay extensions etc.

···

On Jan 2, 2016, at 12:24 AM, Drew Crawford via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

I've noticed that e.g. String is not bridged to NSString. The expected workaround seems to be calling .bridge() everywhere.

1. Is there a plan for bridging e.g. String with NSString?
2. Would it be appropriate to PR in the meantime e.g.

extension String {
        public func cStringUsingEncoding(encoding: UInt) -> UnsafePointer<Int8> {
            return self.bridge().cStringUsingEncoding(encoding)
        }
    }

  3. The README also says

We will also drop the 'NS' prefix from all Foundation classes

...is that the resolution? e.g what is currently class NSString will become instead extension String? Is there a bug open for that?

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