[swift-evolution] Foundation and value types

Dmitri Gribenko gribozavr at gmail.com
Thu Dec 10 19:24:33 CST 2015

On Thu, Dec 10, 2015 at 5:19 PM, Tony Parker <anthony.parker at apple.com> wrote:
> I’m not particularly happy with the existing bridging.
> First, it’s not available on all platforms.
> Second, it’s often inefficient (c.f.
> https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L476,

This is not an issue with bridging.  String needs a different hash
code because it implements == differently, and hash code and equality
semantics have to match.

> https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L159,

In this case, the user explicitly asked to check whether a cast is
possible using 'as?', there is no other way to implement this.  When
it is possible to do a cast lazily, we do it lazily.

> others).
> Third, it causes confusing API discrepancies. e.g. here:
> (https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSError.swift#L47)
>     /// - Experiment: This is a draft API currently under consideration for
> official import into Foundation
>     /// - Note: This API differs from Darwin because it uses [String : Any]
> as a type instead of [String : AnyObject]. This allows the use of Swift
> value types.
>     private var _userInfo: [String : Any]?
> On Darwin this is [String: AnyObject] - but then, why does it accept
> Swift.String, which is clearly not an object? Because of magic stuff
> happening behind your back (which, because of #1, does not happen on Linux).

Yes, we need to make it consistent.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list