<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m not particularly happy with the existing bridging.<div class=""><br class=""></div><div class="">First, it’s not available on all platforms. </div><div class=""><br class=""></div><div class="">Second, it’s often inefficient (c.f. <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L476" class="">https://github.com/apple/swift/blob/master/stdlib/public/core/String.swift#L476</a>, <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L159" class="">https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L159</a>, others).</div><div class=""><br class=""></div><div class="">Third, it causes confusing API discrepancies. e.g. here: (<a href="https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSError.swift#L47" class="">https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSError.swift#L47</a>)</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> /// - Experiment: This is a draft API currently under consideration for official import into Foundation<br class=""> /// - 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.<br class=""> private var _userInfo: [String : Any]?</font></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">I don’t have any silver bullet proposal, but before we go head first into expanding this pattern across many more class/value types, I believe we need a much better answer.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 5:05 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Bridging definitely has to be an important part of the proposal. But<br class="">I want to note that we have existing tools to solve bridging issues<br class="">that we use with existing types -- researching how to apply them would<br class="">be a good start.<br class=""><br class="">Dmitri<br class=""><br class="">On Thu, Dec 10, 2015 at 5:02 PM, Tony Parker <<a href="mailto:anthony.parker@apple.com" class="">anthony.parker@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">Our primary goal for Swift 3 is to achieve API parity with Darwin Foundation.<br class=""><br class="">That said, if we want to talk about value types then the conversation has to start with how the bridging is supposed to work. The vast majority of frameworks on OS X and iOS are implemented in Objective-C and will expect existing Foundation class types in their APIs (e.g. Date and URL).<br class=""><br class="">- Tony<br class=""><br class=""><blockquote type="cite" class="">On Dec 10, 2015, at 4:38 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>> wrote:<br class=""><br class="">On Thu, Dec 10, 2015 at 4:09 PM, Matthew Johnson via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">I am very happy that Swift 3 is placing a priority on portability, especially including a robust library enabling real work to be done.<br class=""><br class="">Adopting Foundation as the library interface is an obvious choice for many reasons. Despite that I find it rather unfortunate that we are tied to an API designed in a different language without the rich feature set Swift has to offer, especially expressive and highly functional value types.<br class=""><br class="">Many of the types in Foundation would naturally be designed as value types in Swift, evidenced by the fact that String, Array, Dictionary and Set are implemented this way in Swift's standard library. I'm sure it would be out of scope for Swift 3, but I am wondering if there are plans to design Swift-native value types corresponding to the Foundation types where that makes sense (Date, URL, etc).<br class=""></blockquote><br class="">It seems to be an area of the library where value types would make a<br class="">lot of sense, so I'd like this conversation to continue. Tony, what<br class="">do you think?<br class=""><br class="">Dmitri<br class=""><br class="">--<br class="">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>>*/<br class=""></blockquote><br class=""></blockquote><br class=""><br class=""><br class="">-- <br class="">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>>*/<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>