[swift-evolution] [Review] SE-0005 Better Translation of Objective-C APIs Into Swift

[swift at lng.la]

> On Feb 1, 2016, at 13:38, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Feb 1, 2016, at 1:02 PM, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>> 
>> Types like NSURL are intended to be the canonical URL for everyone to use,
> 
> 
> I think the "canonical URL for everyone to use" must be a value type / struct.  To me this seems axiomatic.
> 
> Meanwhile (NS)URL cannot be a value type because of the Darwin compatibility mandate, and to change from value->reference semantics would be "off the charts" breakage severity.
> 
> This is a requirements conflict.  corelibs-foundation can either be Darwin-compatible or it can be canonical, but we cannot do both.  Right now we have chosen Darwin-compatible, so we must let the canonical requirement go.   Unprefixed "URL" should be reserved for the value type that can actually work as a canonical API.
> 
> It's not clear to me if Foundation will actually be in a position to provide that API (e.g. in Swift 4, etc.) or whether some third party will provide a "URL" framework that gains traction first.  But in any case, we are not going to do it in the Swift 3 window, unless a lot of core scope decisions get re-decided.

This is a major concern for me as well. I would much rather put up with NS prefixes for a while longer if it means we can improve on Foundation in the future. I think it would be very unfortunate if we forever locked ourselves into Swift anti-patterns like a reference-based URL type (among certainly many others) in what is intended to be like an extension to the Swift standard library.

Jarod

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