<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Riley,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 22, 2016, at 1:34 PM, Riley Testut <<a href="mailto:rileytestut@gmail.com" class="">rileytestut@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""><span class=""></span></div><div class=""><div class=""></div><div class="">Very happy to see this proposal; felt strange that for a language so focused on value-types an entire framework open sourced with the language was composed entirely of reference-types (albeit for obvious reasons). So +1 for that.</div><div class=""><br class=""></div><div class=""></div><div class="">One particular section that caught my interest was this:</div><div class=""><blockquote type="cite" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">The most obvious drawback to using a struct is that the type can no longer be subclassed. At first glance, this would seem to prevent the customization of behavior of these types. However, by publicizing the reference type and providing a mechanism to wrap it (<code style="box-sizing: border-box; padding: 0.2em 0px; margin: 0px; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">mySubclassInstance as ValueType</code>), we enable subclasses to provide customized behavior.</span></blockquote></div><blockquote type="cite" class=""><div class=""></div></blockquote><div class=""><br class=""></div><div class="">I'm incredibly biased, but I recently proposed and submitted a pull request that would introduce "factory initializers" to the language (<a href="https://github.com/apple/swift-evolution/pull/247" class="">https://github.com/apple/swift-evolution/pull/247</a>). The full proposal has more info, but essentially factory initializers would allow for directly returning initialized types from designated factory initializers, similar to how initializers are implemented in Objective-C.</div><div class=""><br class=""></div><div class="">Anyway, I feel the Factory Initializer proposal would work very well with this Foundation proposal. While I believe the current suggestion of casting the reference type as the value type works well, I don't believe it is necessarily the client of the API's job to use it; I believe it would make far more sense for there to be an extension adding additional factory initializers to the class, which would determine the underlying reference type to use based on the input parameters.</div><div class=""><br class=""></div><div class="">For example, here is the example of using a custom subclass for the Data type mentioned in this Foundation proposal:</div><div class=""><pre style="box-sizing: border-box; word-wrap: normal; margin-top: 0px; margin-bottom: 0px; padding: 16px; overflow: auto; line-height: 1.45; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal;" class=""><blockquote type="cite" class=""><font face="UICTFontTextStyleBody" class=""><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);" class=""><span class="pl-c" style="box-sizing: border-box;">/// Create a Data with a custom backing reference type.</span></span></font></blockquote><blockquote type="cite" class=""><font face="UICTFontTextStyleBody" class=""><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);" class=""><span class="pl-k" style="box-sizing: border-box;">class</span> MyData <span class="pl-k" style="box-sizing: border-box;">:</span> NSData { }</span></font></blockquote><blockquote type="cite" class=""><font face="UICTFontTextStyleBody" class=""><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);" class="">
<span class="pl-k" style="box-sizing: border-box;">let</span> dataReference <span class="pl-k" style="box-sizing: border-box;">=</span> MyData()</span></font></blockquote><blockquote type="cite" class=""><font face="UICTFontTextStyleBody" class=""><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);" class=""><span class="pl-k" style="box-sizing: border-box;">let</span> dataValue <span class="pl-k" style="box-sizing: border-box;">=</span> dataReference <span class="pl-k" style="box-sizing: border-box;">as</span> Data
<span class="pl-c" style="box-sizing: border-box;">// dataValue copies dataReference </span></span></font></blockquote></pre></div><div class="">I personally would rather see something akin to this:</div><div class=""><br class=""></div><div class="">public extension Data {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>factory init(inputData: ...)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>{</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if ... {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Return subclass best suited for storing this particular input data</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return MyData(inputData) as Data</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>else {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let data = NSData()</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/* OMITTED: add hypothetical inputData to NSData depending on what it is */</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return data </div><div class="">}</div><div class=""><br class=""></div><div class="">This means the client of the API never has to worry about which subclass is best suited for them; everything would "just work". This also better mimics the existing class cluster pattern in Foundation, which might help with this transition should my proposal be accepted.</div><div class=""><br class=""></div><div class="">Regardless though, very happy to see this being pushed forward. Just thought I'd suggest ways to make this proposal (hopefully) easier to both implement and use :)</div></div></div></div></div></blockquote><div><br class=""></div>Thanks for your feedback.</div><div><br class=""></div><div>For what it’s worth, I’m fully in support of your factory type proposal as well. I think we need it in order to finish a complete implementation of swift-corelibs-foundation, at the very least.</div><div><br class=""></div><div>We can certainly extend these types to include use of the factory types once we get them into the language.</div><div><br class=""></div><div>- Tony</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">On Apr 22, 2016, at 12:52 PM, Tony Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi David,<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 22, 2016, at 12:13 PM, David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Amazing, I am really looking forward to this feature!<div class=""><br class=""></div><div class="">Comments:</div><div class=""><br class=""></div><div class="">- For Locale and Calendar, one possible Swift layout would be to synthesize a protocol and to use that to represent bridged API. You could then bridge inbound to either the immutable value type or the dynamic class-based type. On the swift side, these are constructed as two distinct types.</div></div></div></blockquote><div class=""><br class=""></div><div class="">That’s an interesting approach, I’ll consider that for these.</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="">- For any of these types, are there improvements (similar to String) which would be worth making before exposing ’the’ Swift type and API? The ones I’m specifically worried about are Date and URL, since I’ve seen so many standard language time and networking API show their age over time.</div><div class=""><br class=""></div><div class="">-DW</div></div></div></blockquote><div class=""><br class=""></div><div class="">We’re absolutely going to be making Swift-specific improvements to many of these types. I think the resulting API is better in many ways. For example, on URL the main improvement is that the resource values dictionary is now struct type with a lot of strongly-typed properties. It’s still got a lot of optionals because of the way that the underlying fetch works, but it’s better. Date gains mutating methods along with support for operators like += and < >. </div><div class=""><br class=""></div><div class="">One of the guiding principles of our effort was evolution over revolution. Foundation is obviously used in tons and tons of API. We want to maintain conceptual compatibility with the entire OS X / iOS / watchOS / tvOS SDK when it is imported into Swift. Hopefully this also means that converting from reference to value types in your own uses of these API does not require a complete rethink of how you use them, but still provide the benefits outlined in the proposal. We’ll continue to iterate and improve over time.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">- Tony</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=""> </div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 22, 2016, at 11:18 AM, Tony Parker 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear swift-evolution denizens,<div class=""><br class=""></div><div class="">As you know from our announcement of Swift Open Source and our work on naming guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We want to to make the cross-platform Foundation API that is available as part of swift-corelibs feel like it is not tied to just Darwin targets. We also want to reinforce the idea that new Foundation API must fit in with the language, standard library, and the rapidly evolving design patterns we see in the community.</div><div class=""><br class=""></div><div class="">You challenged us on one part of this plan: some Foundation API just doesn’t “feel Swifty”, and a large part of the reason why is that it often does not have the same value type behavior as other Swift types. We took this feedback seriously, and I would like to share with you the start of an important journey for some of the most commonly used APIs on all of our platforms: adopting value semantics for key Foundation types.</div><div class=""><br class=""></div><div class="">We have been working on this for some time now, and the set of diffs that result from this change is large. At this point, I am going to focus effort on an overview of the high level goals and not the individual API of each new type. In order to focus on delivering something up to our quality standards, we are intentionally leaving some class types as-is until a future proposal. If you don’t see your favorite class on the list — don’t despair. We are going to iterate on this over time. I see this as the start of the process.</div><div class=""><br class=""></div><div class="">One process note: we are still trying to figure out the best way to integrate changes to API that ship as part of the operating system (which includes Foundation) into the swift-evolution review process. Swift-evolution is normally focused on changes to functionality in the compiler or standard library. In general, I don’t expect all new Foundation API introduced in the Darwin/Objective-C framework to go through the open source process. However, as we’ve brought up this topic here before, I felt it was important to bring this particular change to the swift-evolution list.</div><div class=""><br class=""></div><div class="">As always I welcome your feedback.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md</a></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Tony</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></body></html>