[swift-evolution] Foundation and value types

[Matthew Johnson]

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).

I am also wondering how this would interact with the decision to drop the NS prefixes from the names of Foundation types.  For example, if a hypothetical Date value type exists in a future version of Swift and NSDate is also named Date in Swift any code importing both Foundation and the module containing the Swift-native Date type (would this be in the standard library?) would need to manually resolve the name ambiguity every time it was used.  This is obviously less than ideal.  

I am guessing there is at least a vague conception of a more Swifty Foundation and a plan to somehow address the issue of conflicting names.  If there is I am interested in having some idea of where we are headed.

I ask partly out of a desire to use value types for things that are naturally values and partly because I am wondering if there is anything the community can reasonbly do in the near term to expedite the process of getting to a more Swifty Foundation API beyond helping to complete a robust and well tested corelibs implementation of Foundation.

Thanks,
Matthew