bridging (SR-138)


(Drew Crawford) #1

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 Smiley) #2

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

https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Issues.md#known-issues

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) #3

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