<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 3:38 PM, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 1:02 PM, Tony Parker <<a href="mailto:anthony.parker@apple.com" class="">anthony.parker@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Types like NSURL are intended to be the canonical URL for everyone to use,</span></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">I think the "canonical URL for everyone to use" <b class="">must</b> be a value type / struct. To me this seems axiomatic.</div><div class=""><br class=""></div><div class="">Meanwhile (NS)URL <b class="">cannot</b> be a value type because of the Darwin compatibility mandate, and to change from value->reference semantics would be "off the charts" breakage severity.</div><div class=""><br class=""></div><div class="">This is a requirements conflict. corelibs-foundation can either be Darwin-compatible <b class="">or</b> 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.</div></div></div></blockquote><div><br class=""></div><div>+1. I was pretty shocked by that sentence as well. The intention to canonize reference types just because they already exist could not be INVHO further from the right intention for Swift. I understand and accept the short-term rationale for leveraging them. I do not understand why we would settle for them as the long-term canonical solution.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>