[swift-evolution] Foundation and value types

Philippe Hausler phausler at apple.com
Thu Dec 10 19:10:01 CST 2015

I think some may have a more persuasive argument than others: NSDate for example seems much more cut and dry since it is basically just a simple wrapper around a Double. It is worth mentioning that one of the distinct advantages of the class versions is that they are subclassable. Granted that may not apply to all users but it is a pretty useful thing to have a good concrete base class to derive from that works well with other APIs. NSOperation for example probably would not be a good candidate since most all cases of it’s usage is a subclass. URL I am on the fence because one of the major issues with going to a struct type is that it would likely loose the functionality granted by lower level APIs like CFURLRef which some of that nuances I would hope would be developed in one canonical location.

> On Dec 10, 2015, at 5:02 PM, Tony Parker via swift-evolution <swift-evolution at swift.org> 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>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list