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