[swift-corelibs-dev] bridging (SR-138)

Philippe Hausler phausler at apple.com
Sat Jan 2 02:57:52 CST 2016


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160102/c65358b8/attachment.html>


More information about the swift-corelibs-dev mailing list