[swift-evolution] Foundation and value types

[Tony Parker]

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, https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift#L159, 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).

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.

- Tony

> On Dec 10, 2015, at 5:05 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> Bridging definitely has to be an important part of the proposal.  But
> I want to note that we have existing tools to solve bridging issues
> that we use with existing types -- researching how to apply them would
> be a good start.
> 
> Dmitri
> 
> On Thu, Dec 10, 2015 at 5:02 PM, Tony Parker <anthony.parker at apple.com> wrote:
>> Our primary goal for Swift 3 is to achieve API parity with Darwin Foundation.
>> 
>> 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).
>> 
>> - Tony
>> 
>>> On Dec 10, 2015, at 4:38 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> On Thu, Dec 10, 2015 at 4:09 PM, Matthew Johnson via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>>> I am very happy that Swift 3 is placing a priority on portability, especially including a robust library enabling real work to be done.
>>>> 
>>>> 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.
>>>> 
>>>> 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).
>>> 
>>> It seems to be an area of the library where value types would make a
>>> lot of sense, so I'd like this conversation to continue.  Tony, what
>>> do you think?
>>> 
>>> Dmitri
>>> 
>>> --
>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>> 
> 
> 
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/32a42e97/attachment.html>