Hi Matthew,
Sent from my iPad
Hi Tony,
I'm very positive about the proposal but I have similar fears, even if less strong, to David Waite. I agree that the core libraries can be improved with time, but it's going to be difficult to rethink them profoundly. NSKeyedArchiver was an improvement, but a fairly mild one, to stay backwards-compatible. It's going to be difficult to introduce major changes, like the ones David Waite gave as example, post Swift 3.
But on a more pragmatic level, I know there is not much we can do about it, with the current deadlines. All we can hope for is make corelibs-foundation as Swifty as possible by the time Swift 3 comes out. And I imagine that third party libraries will come to replace the aspects of it that feel too alien to Swift.
Any thoughts?
+1. I have similar concerns. The worst case would be if Foundation does not eventually get the appropriate Swift-native rethinking and third party libraries with the same functionality are developed for that reason. If that happens the community will be split between those who favor various libraries. That should not happen just because corelibs doesn't feel Swift-native.
It would be far better to see that happen as part of the evolution process so we eventually end up with fully Swift-native types in Foundation itself. I think a strong commitment to doing this over the next couple years would go a long way towards addressing the concerns many of us have about this.
I totally understand what you’re saying. I believe we’ve made that commitment, by virtue of placing Foundation (dispatch and XCTest too) into swift-corelibs and also by sending this proposal and the value types one to this list. We are trying to avoid exactly the split you are concerned about.
There is always going to be new functionality in Foundation and other frameworks in the SDK that is tied to OS releases, which we simply cannot talk about here until those releases are made public. However, the rest of the Foundation team and I are always advocating for the best possible Swift API wherever and whenever we can.
There is no doubt it will take time to make the many thousands of APIs that you use every day feel native and natural in Swift. I’ll beat the drum of iterative improvement again: the best way to get there from here is to make continuous adjustments and improvements from release to release. You will see the rethinking you are looking for over the course of that process.
Thank you for the reply and openness Tony.
I think our concern stems from a couple of places. Possibly most important is that there has been significant effort to introduce as many breaking changes into Swift 3 as possible and a general sense that there will be a pretty high bar for breaking changes in the future. Many of changes we hope to see in a Swift native rethink / redesign will be significant breaking changes if they are made to the existing types. We are focused on the *design* of the APIs, not just the naming of specific methods. Their Cocoa and Objective-C origin will be quite apparent despite the renaming which will make them somewhat more comfortable in Swift. Is there really appetite for making breaking changes on the scale necessary for a Swift native design in Swift 4, 5, 6, etc (assuming it takes several iterations to complete)?
Secondarily, as long as the design of Foundation is constrained by the need to be usable from Objective-C this constraint is likely to influence the Swift interface in some way. I imagine this constraint will be around for a while quite a while. That could slow the the arrival of designs that are true to the spirit of Swift.
I understand the need for pragmatism and appreciate the desire to make our experience in Swift 3 be as pleasant as possible. At the same time, I fear that taking the approach of evolving Foundation as the long term strategy will lead to a suboptimal result and / or the split in the community I mentioned. There are several factors that could contribute to this:
1. Evolving existing API rather than designing from scratch will lead to different results. Designing from scratch will likely lead to a better result from a "pure Swift" perspective as there will not be any legacy baggage.
2. If the underlying implementation is going to need to be available in Objective-C as well for quite a while it will probably delay highly desired changes, thus leaving a window where the community may split.
3. We may reach a place in 3 years where everyone acknowledges the library API are not close to what we would design if we could do it over, but the will for breaking changes of the scale necessary just isn't there.
Can you elaborate on why Foundation must be the long term solution? I wonder if it wouldn't be better if the long term solution was a new, Swift native module. This would allow us to make Foundation more comfortable in the near term while avoiding breaking changes when Swift native designs are introduced. It would also encourage community members who wish to design something more Swifty to work on that as part of the evolution process or as a precursor to evolution (along the lines of Boost).
If Foundation must be the long term solution it looks to me like these are our options:
1. Keep the NS prefixes until types are redesigned.
2. Face significant breaking changes in the future when Swift native designs are introduced
3. Live with designs in Foundation that don't feel Swift native, likely leading to an alternative from the community that feels more Swifty.
If these are the options we have available my preference is for #1. However, maybe we can achieve the benefits of this approach while simultaneously enabling a more comfortable Foundation experience in the near term simply by deciding to treat Foundation as a bridge to a future that will eventually move beyond it.
Matthew
···
Sent from my iPad
On May 7, 2016, at 11:14 AM, Tony Parker <anthony.parker@apple.com> wrote:
On May 7, 2016, at 5:22 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On May 7, 2016, at 5:03 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Thanks,
- Tony
David (Hart).
On 07 May 2016, at 00:06, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:
Hi David,
On May 6, 2016, at 2:56 PM, David Waite <david@alkaline-solutions.com> wrote:
-1 On the group as-is. I do not believe all of these classes have the behavior that would be expected if ‘foundation’ were a from-scratch foundational library for Swift (as it exists on non Apple platforms). This will lock Swift into an evolutionary path for these types going forward.
There is enough here that I will just pick one example to focus on - NSCoding/NSCoder, and elements I would suspect from such a from-scratch design
- Coding would incorporate SecureCoding into its design (I did not see NSSecureCoding even on the list of protocols to get the prefix dropped)
SecureCoding should be on the list actually.
- Archiver/Unarchiver would not exist; we would only have keyed versions
- Coder would be a split in half to Coder and Decoder
- Coder and Decoder would be protocols
- The Coder protocol might have a single method, encode(value:Coding, forKey:String)
- The Decoder protocol might single method, <T:Coding> decode(type:T.Type, forKey: String) -> T?
- Compiler generation of a default Coding implementation
And possibly more such as:
- Add Coders limited to trees of objects vs graphs, to allow the Coder/Decoder protocols to be used for more intuitive JSON/XML representations
- Custom/specific assignment operator for Decoder to capture desired type without requiring said type to be specified in decode(type:forKey:) calls
-DW
There’s no question that we can improve Coding for Swift. I have actually explored this area quite a bit although I don’t have anything planned for Swift 3 at this time.
The general point is though, that we can do it by extending Foundation in that direction over time. In fact, keyed archiving is the perfect example of how we were able to do just that in the past in Objective-C. NSArchiver already existed and served a particular purpose, so we extended the concept into NSKeyedArchiver using the facilities available to us at the time.
It’s not a goal to rewrite Foundation from scratch in Swift. All Swift apps that are running out there today are in fact using a combination of Swift, Objective-C, C, C++, various flavors of assembly, and more. The goal is to present the existing API of Foundation in a way that fits in with the language today while allowing us to iteratively improve it over time.
- Tony
On May 6, 2016, at 2:52 PM, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:
Hi everyone,
Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). I’m back again with more information on another part of our plan to integrate Foundation API into Swift: dropping the NS prefix.
When we originally proposed this as part of the API guidelines document (SE-0023, https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md\), we took a very broad approach to which classes would drop their prefix. This time, we’ve narrowed the scope considerably, plus taken advantage of the ability to nest types inside classes to further reduce the possibility of introducing conflicting names.
I’ve written up a draft of the proposal, which includes an extensive section on motivation plus a list of changes. Please take a look and let me know what you think. We’ll start a formal review period soon.
https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md
Thanks again for your help,
- Tony
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution