<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=""><div><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 13:38, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><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><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 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></div></blockquote><div><br class=""></div><div><div class="">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.</div><div class=""><br class=""></div><div class="">Jarod</div></div></div><br class=""></body></html>