Dropping NS Prefix in Foundation


(Jon Hull) #1

-1 on this as well. How much does dropping NS really help things anyway?

All it does is force everyone to learn which things still have NS and which don’t. It also makes things much more difficult to search for… searching for NS_ gives the results you want quickly vs searching for anything in Swift foundation (e.g. Array -- which gives you a mixture of other programming languages and Taylor Swift gossip).

My proposal would be to keep NS for everything and then slowing making versions without the prefix, either by rewriting them to be better in Swift or simply aliasing the NS version. Once you have critical mass for useful things (around Swift 5~6), you can separate all the NSStuff out into their own NSFoundation which would be used only for backwards compatibility.

To the inevitable question: Wont having NS and Non-NS versions be confusing (especially if some are just aliases)? My answer is that it is less confusing than this proposal. There is a simple rule: Things without NS are always the new and preferred methods. Things with NS are there for compatibility and will continue to work the way they do in ObjectiveC (even if you have to import “NSFoundation” to get them instead of just “Foundation")

Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.

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.

I would be curious to hear about your explorations (either in another thread or offlist)

I have written a couple of experimental versions of an improved Coding system for Swift. The key idea is to use closures to allow coding of arbitrarily complex nested types (e.g an array of tuples of Dictionaries: [(String, [String:Int])] ). It works pretty well, but unfortunately currently taxes the compiler to the point where it randomly crashes during compilation. I am waiting for the new generics stuff to come online before I explore further, since I believe that will dramatically simplify the code.

The other idea which I would like to see replicated is that it codes to an intermediate format which can then be transformed to/from binary data, XML, BSON (JSON + some representation for Binary Data) or some other format...

It also interoperates very well with existing NSCoding classes, which is an important feature.

Thanks,
Jon


(Tony Parker) #2

-1 on this as well. How much does dropping NS really help things anyway?

All it does is force everyone to learn which things still have NS and which don’t. It also makes things much more difficult to search for… searching for NS_ gives the results you want quickly vs searching for anything in Swift foundation (e.g. Array -- which gives you a mixture of other programming languages and Taylor Swift gossip).

My proposal would be to keep NS for everything and then slowing making versions without the prefix, either by rewriting them to be better in Swift or simply aliasing the NS version. Once you have critical mass for useful things (around Swift 5~6), you can separate all the NSStuff out into their own NSFoundation which would be used only for backwards compatibility.

To the inevitable question: Wont having NS and Non-NS versions be confusing (especially if some are just aliases)? My answer is that it is less confusing than this proposal. There is a simple rule: Things without NS are always the new and preferred methods. Things with NS are there for compatibility and will continue to work the way they do in ObjectiveC (even if you have to import “NSFoundation” to get them instead of just “Foundation")

I think that this approach ends up with confusion as well. Maybe we end up with UserDefaults and NSUserDefaults? One is written in Swift and other is not, but what difference would that make to the caller? Swift itself is not written completely in Swift. Instead, let’s have one UserDefaults that has an API appropriate for Swift. You’ve seen some of that already with changes to the names of its methods (https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575 as one example, which takes advantage of overloading to simplify the API).

Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.

NSAttributedString was part of the value types proposal at the beginning but deferred for a few practical reasons. One reason is that I want additional existential support in the language first. AttributedString has the concept of a “longest effective run”, which is calculated by checking for equality between attributes. Attributed string should allow for AnyEquatableAndCopyable members of its attribute dictionary. A second problem is that the entire Cocoa text system (and hundreds of higher level APIs) are based on top of the NSString Index concept, which is hidden behind the unicodeScalar view of Swift.String. I would like a more unified story of how these two can interoperate before we revamp the base type.

Both of these are solvable, but they require time to collaborate between teams to decide what the right platform-wide approach is. We’ll do it, but it will not happen immediately.

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.

I would be curious to hear about your explorations (either in another thread or offlist)

I have written a couple of experimental versions of an improved Coding system for Swift. The key idea is to use closures to allow coding of arbitrarily complex nested types (e.g an array of tuples of Dictionaries: [(String, [String:Int])] ). It works pretty well, but unfortunately currently taxes the compiler to the point where it randomly crashes during compilation. I am waiting for the new generics stuff to come online before I explore further, since I believe that will dramatically simplify the code.

The other idea which I would like to see replicated is that it codes to an intermediate format which can then be transformed to/from binary data, XML, BSON (JSON + some representation for Binary Data) or some other format...

It also interoperates very well with existing NSCoding classes, which is an important feature.

Thanks,
Jon

One thing to think about here is what the role of NSCoding is in the first place. It was designed to support archiving of UI objects to nib files. It has been pressed into service for all kinds of other interesting tasks since; UI state restoration, document formats, and IPC wire protocol, to name a few. It may be worthwhile to decide if these are really all the same use case or not. I’m honestly not sure yet. Some of these are very focused on dynamic behavior (that is, the object graph is not known in advance). For some, custom object types are really important (NSXPC takes full advantage of this, and is basically its reason for existence over the raw libxpc API). For others it is not (a raw document file of one million double values). Some of these have different performance requirements than others (archiving fast is important to IPC but unarchiving fast is important to loading nib files).

- Tony

···

On May 7, 2016, at 6:06 AM, Jonathan Hull <jhull@gbis.com> wrote:


(Jon Hull) #3

-1 on this as well. How much does dropping NS really help things anyway?

All it does is force everyone to learn which things still have NS and which don’t. It also makes things much more difficult to search for… searching for NS_ gives the results you want quickly vs searching for anything in Swift foundation (e.g. Array -- which gives you a mixture of other programming languages and Taylor Swift gossip).

My proposal would be to keep NS for everything and then slowing making versions without the prefix, either by rewriting them to be better in Swift or simply aliasing the NS version. Once you have critical mass for useful things (around Swift 5~6), you can separate all the NSStuff out into their own NSFoundation which would be used only for backwards compatibility.

To the inevitable question: Wont having NS and Non-NS versions be confusing (especially if some are just aliases)? My answer is that it is less confusing than this proposal. There is a simple rule: Things without NS are always the new and preferred methods. Things with NS are there for compatibility and will continue to work the way they do in ObjectiveC (even if you have to import “NSFoundation” to get them instead of just “Foundation")

I think that this approach ends up with confusion as well. Maybe we end up with UserDefaults and NSUserDefaults? One is written in Swift and other is not, but what difference would that make to the caller? Swift itself is not written completely in Swift. Instead, let’s have one UserDefaults that has an API appropriate for Swift. You’ve seen some of that already with changes to the names of its methods (https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575 as one example, which takes advantage of overloading to simplify the API).

I think my main point here is that just because we are making breaking changes in Swift 3, it doesn’t mean we have to do everything as a breaking change. I feel like we are being hasty in trying to bring everything over so quickly without thought, when it could be done gradually over 3-4 years… making large improvements as we pull things over. If we do this now, we will be locking ourselves into a base design that will always be between two worlds, and thus not really ideal for either world. Lowest common denominator. We won’t be able to do things like Swift’s String or Array.

In cases like UserDefaults where it makes sense to pull over the design without much modification, you can have a single design and just alias it to “UserDefaults”

There will be confusion with any system, but this at least has a simple clarifying rule. If there is both a NS and Non-NS version, the non-NS version is the new/shiny/preferred one.

What happens if we just bring something like NSURL over and call it URL, but then decide we need a completely different conceptual model (or we want to make it a value type instead of a reference type)? All of the non-breaking fixes I can think of are way more confusing than having separate NSURL and Url types (which mirror the differences of NSArray and Array).

Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.

NSAttributedString was part of the value types proposal at the beginning but deferred for a few practical reasons. One reason is that I want additional existential support in the language first. AttributedString has the concept of a “longest effective run”, which is calculated by checking for equality between attributes. Attributed string should allow for AnyEquatableAndCopyable members of its attribute dictionary. A second problem is that the entire Cocoa text system (and hundreds of higher level APIs) are based on top of the NSString Index concept, which is hidden behind the unicodeScalar view of Swift.String. I would like a more unified story of how these two can interoperate before we revamp the base type.

Both of these are solvable, but they require time to collaborate between teams to decide what the right platform-wide approach is. We’ll do it, but it will not happen immediately.

Makes sense.

I think what I would like to see is a new model which makes editing & creation much less of a pain, but which can be bridged to NSAttributedString so we don’t have to propagate changes (e.g. the indexing model) throughout the system all at once.

My main opposition to bringing everything over right now is that it makes changes like that much more difficult in the future.

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.

I would be curious to hear about your explorations (either in another thread or offlist)

I have written a couple of experimental versions of an improved Coding system for Swift. The key idea is to use closures to allow coding of arbitrarily complex nested types (e.g an array of tuples of Dictionaries: [(String, [String:Int])] ). It works pretty well, but unfortunately currently taxes the compiler to the point where it randomly crashes during compilation. I am waiting for the new generics stuff to come online before I explore further, since I believe that will dramatically simplify the code.

The other idea which I would like to see replicated is that it codes to an intermediate format which can then be transformed to/from binary data, XML, BSON (JSON + some representation for Binary Data) or some other format...

It also interoperates very well with existing NSCoding classes, which is an important feature.

Thanks,
Jon

One thing to think about here is what the role of NSCoding is in the first place. It was designed to support archiving of UI objects to nib files. It has been pressed into service for all kinds of other interesting tasks since; UI state restoration, document formats, and IPC wire protocol, to name a few. It may be worthwhile to decide if these are really all the same use case or not. I’m honestly not sure yet. Some of these are very focused on dynamic behavior (that is, the object graph is not known in advance). For some, custom object types are really important (NSXPC takes full advantage of this, and is basically its reason for existence over the raw libxpc API). For others it is not (a raw document file of one million double values). Some of these have different performance requirements than others (archiving fast is important to IPC but unarchiving fast is important to loading nib files).

Makes sense. I haven’t really worried to much about efficiency in my experiments (I am just trying to get it to work at all), but I can see where that will be important for the official version.

I wonder if protocols help us here? They might allow us to swap out implementations and have something optimized for the situation (e.g. your file of one million double values).

It definitely warrants significant thought and design. It sounds like a Swift 4 thing, though I continually hope for Swift 3, as it is the main issue (i.e. How do I save information stored in value types?) stalling real-world projects which I have in the pipeline. If improved generics make their way into Swift 3, it should be enough, as we can make custom frameworks (which don’t crash the compiler) to do the job until the official version is ready...

Thanks,
Jon

···

On May 7, 2016, at 9:53 AM, Tony Parker <anthony.parker@apple.com> wrote:

On May 7, 2016, at 6:06 AM, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:


(Patrick Smith) #4

I think everyone possibly has different definitions of what ‘Swift-native rethinking’ could involve? My thoughts are, the Swift standard library is a base library of types and algorithms. There’s then a sister library that has serialisation, file reading and writing, and HTTP networking, dates, and more. At the moment that library is Foundation.

I think a good rule for Swift 3 has been, if some feature wasn’t already in, would it be added now if freshly proposed? Is it too far to ask what would a fresh take on Foundation look like?

There are certain things with Foundation that make it feel outdated or possibly less Swift-like:
- File references/paths are currently a part of NSURL. While this is 10 times better than the old NSString API, isn’t it still a bit odd, and a bit unfortunate to be bringing forward to Linux? There are a whole set of APIs of NSURL that only apply to files, and other another set that only apply to actual RFC 2396 URLs. Plus you have the NSFileManager APIs and the NSURLSession APIs, one for files and one for web URLs, and they both use the same type.
- Why does the library Alamofire have 16,000 stars given that it uses the relatively new API NSURLSession? Would a Swift Foundation aim to get a similar API?
- NSTask I think is a reasonable Objective-C API, but nowadays is verbose and throws exceptions: https://www.shinobicontrols.com/blog/scripting-in-swift
- NSUserDefaults is designed to write to file storage by a single client as far as I know. i.e. would it be appropriate for a web server?
- Foundation is originally designed in a time before closures and before GCD. It’s had some additions to work those features in, but they don’t feel like Foundation has been based upon them.
- Having two types, the [NS]OutputStream class, and the OutputStreamable protocol, but they seemingly have nothing to do with each other? Why the designs of one or both change so that NSOutputStream could conform to OutputStreamable?
- APIs such as NSOperation that rely on key value coding and observation.
- NSOperationQueue, which back in its day added a nice Objective-C API over dispatch queues, but today could probably be achieved by use of protocol extensions and a smaller class that complement GCD?
- NSSortDescriptor, designed using key value coding.

Matthew Johnson raised the possibility of a “split between those who favor various libraries”. I take your point that “We are trying to avoid exactly the split you are concerned about.”

I think it is worth listing what Swift-native thinking includes. Here are my ideas based on what I’ve seen from the standard library and the community:
- Modular protocol oriented design
- Small focused APIs
- Elegant use of closures
- Explicit rejection of old conventions in order to find the best possible API
- Value types of course, which we have coming thanks to the effort here
- Ability to design with ‘micro’ value types, where objects would have been cumbersome or inefficient in Objective-C.

I have a feeling that for developers who start by learn Swift conventions and who know have exposure to other libraries and frameworks, that Foundation will feel a bit foreign to them. I feel there will be a split between library choices, as people go for something with more focused APIs that take advantage of Swift more. Is the plan for Foundation to still be a core part of Swift in the next 5+ years?

Foundation is a great API for the tools they had available with Objective-C and thoughtful naming and design. I feel if someone were to design an API given the current tools we have now, it would be very different.

I think modernising Foundation for Swift is a worthy effort, but seemingly making it the defacto sister library to the standard library feels a bit odd.

···

On 8 May 2016, at 2:53 AM, Tony Parker via swift-evolution <swift-evolution@swift.org> wrote:

On May 7, 2016, at 6:06 AM, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:

-1 on this as well. How much does dropping NS really help things anyway?

All it does is force everyone to learn which things still have NS and which don’t. It also makes things much more difficult to search for… searching for NS_ gives the results you want quickly vs searching for anything in Swift foundation (e.g. Array -- which gives you a mixture of other programming languages and Taylor Swift gossip).

My proposal would be to keep NS for everything and then slowing making versions without the prefix, either by rewriting them to be better in Swift or simply aliasing the NS version. Once you have critical mass for useful things (around Swift 5~6), you can separate all the NSStuff out into their own NSFoundation which would be used only for backwards compatibility.

To the inevitable question: Wont having NS and Non-NS versions be confusing (especially if some are just aliases)? My answer is that it is less confusing than this proposal. There is a simple rule: Things without NS are always the new and preferred methods. Things with NS are there for compatibility and will continue to work the way they do in ObjectiveC (even if you have to import “NSFoundation” to get them instead of just “Foundation")

I think that this approach ends up with confusion as well. Maybe we end up with UserDefaults and NSUserDefaults? One is written in Swift and other is not, but what difference would that make to the caller? Swift itself is not written completely in Swift. Instead, let’s have one UserDefaults that has an API appropriate for Swift. You’ve seen some of that already with changes to the names of its methods (https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575 as one example, which takes advantage of overloading to simplify the API).

Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.

NSAttributedString was part of the value types proposal at the beginning but deferred for a few practical reasons. One reason is that I want additional existential support in the language first. AttributedString has the concept of a “longest effective run”, which is calculated by checking for equality between attributes. Attributed string should allow for AnyEquatableAndCopyable members of its attribute dictionary. A second problem is that the entire Cocoa text system (and hundreds of higher level APIs) are based on top of the NSString Index concept, which is hidden behind the unicodeScalar view of Swift.String. I would like a more unified story of how these two can interoperate before we revamp the base type.

Both of these are solvable, but they require time to collaborate between teams to decide what the right platform-wide approach is. We’ll do it, but it will not happen immediately.

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.

I would be curious to hear about your explorations (either in another thread or offlist)

I have written a couple of experimental versions of an improved Coding system for Swift. The key idea is to use closures to allow coding of arbitrarily complex nested types (e.g an array of tuples of Dictionaries: [(String, [String:Int])] ). It works pretty well, but unfortunately currently taxes the compiler to the point where it randomly crashes during compilation. I am waiting for the new generics stuff to come online before I explore further, since I believe that will dramatically simplify the code.

The other idea which I would like to see replicated is that it codes to an intermediate format which can then be transformed to/from binary data, XML, BSON (JSON + some representation for Binary Data) or some other format...

It also interoperates very well with existing NSCoding classes, which is an important feature.

Thanks,
Jon

One thing to think about here is what the role of NSCoding is in the first place. It was designed to support archiving of UI objects to nib files. It has been pressed into service for all kinds of other interesting tasks since; UI state restoration, document formats, and IPC wire protocol, to name a few. It may be worthwhile to decide if these are really all the same use case or not. I’m honestly not sure yet. Some of these are very focused on dynamic behavior (that is, the object graph is not known in advance). For some, custom object types are really important (NSXPC takes full advantage of this, and is basically its reason for existence over the raw libxpc API). For others it is not (a raw document file of one million double values). Some of these have different performance requirements than others (archiving fast is important to IPC but unarchiving fast is important to loading nib files).

- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Smith) #5

I think everyone possibly has different definitions of what ‘Swift-native rethinking’ could involve? My thoughts are, the Swift standard library is a base library of types and algorithms. There’s then a sister library that has serialisation, file reading and writing, and HTTP networking, dates, and more. At the moment that library is Foundation.

I think a good rule for Swift 3 has been, if some feature wasn’t already in, would it be added now if freshly proposed? Is it too far to ask what would a fresh take on Foundation look like?

There are certain things with Foundation that make it feel outdated or possibly less Swift-like:
- File references/paths are currently a part of NSURL. While this is 10 times better than the old NSString API, isn’t it still a bit odd, and a bit unfortunate to be bringing forward to Linux? There are a whole set of APIs of NSURL that only apply to files, and other another set that only apply to actual RFC 2396 URLs. Plus you have the NSFileManager APIs and the NSURLSession APIs, one for files and one for web URLs, and they both use the same type.
- Why does the library Alamofire have 16,000 stars given that it uses the relatively new API NSURLSession? Would a Swift Foundation aim to get a similar API?
- NSTask I think is a reasonable Objective-C API, but nowadays is verbose and throws exceptions: https://www.shinobicontrols.com/blog/scripting-in-swift
- NSUserDefaults is designed to write to file storage by a single client as far as I know. i.e. would it be appropriate for a web server?

For what it’s worth, this isn’t true. NSUserDefaults supports concurrent access from arbitrary numbers of clients.

  David

···

On May 7, 2016, at 11:37 AM, Patrick Smith via swift-evolution <swift-evolution@swift.org> wrote:

- Foundation is originally designed in a time before closures and before GCD. It’s had some additions to work those features in, but they don’t feel like Foundation has been based upon them.
- Having two types, the [NS]OutputStream class, and the OutputStreamable protocol, but they seemingly have nothing to do with each other? Why the designs of one or both change so that NSOutputStream could conform to OutputStreamable?
- APIs such as NSOperation that rely on key value coding and observation.
- NSOperationQueue, which back in its day added a nice Objective-C API over dispatch queues, but today could probably be achieved by use of protocol extensions and a smaller class that complement GCD?
- NSSortDescriptor, designed using key value coding.

Matthew Johnson raised the possibility of a “split between those who favor various libraries”. I take your point that “We are trying to avoid exactly the split you are concerned about.”

I think it is worth listing what Swift-native thinking includes. Here are my ideas based on what I’ve seen from the standard library and the community:
- Modular protocol oriented design
- Small focused APIs
- Elegant use of closures
- Explicit rejection of old conventions in order to find the best possible API
- Value types of course, which we have coming thanks to the effort here
- Ability to design with ‘micro’ value types, where objects would have been cumbersome or inefficient in Objective-C.

I have a feeling that for developers who start by learn Swift conventions and who know have exposure to other libraries and frameworks, that Foundation will feel a bit foreign to them. I feel there will be a split between library choices, as people go for something with more focused APIs that take advantage of Swift more. Is the plan for Foundation to still be a core part of Swift in the next 5+ years?

Foundation is a great API for the tools they had available with Objective-C and thoughtful naming and design. I feel if someone were to design an API given the current tools we have now, it would be very different.

I think modernising Foundation for Swift is a worthy effort, but seemingly making it the defacto sister library to the standard library feels a bit odd.

On 8 May 2016, at 2:53 AM, Tony Parker via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On May 7, 2016, at 6:06 AM, Jonathan Hull <jhull@gbis.com <mailto:jhull@gbis.com>> wrote:

-1 on this as well. How much does dropping NS really help things anyway?

All it does is force everyone to learn which things still have NS and which don’t. It also makes things much more difficult to search for… searching for NS_ gives the results you want quickly vs searching for anything in Swift foundation (e.g. Array -- which gives you a mixture of other programming languages and Taylor Swift gossip).

My proposal would be to keep NS for everything and then slowing making versions without the prefix, either by rewriting them to be better in Swift or simply aliasing the NS version. Once you have critical mass for useful things (around Swift 5~6), you can separate all the NSStuff out into their own NSFoundation which would be used only for backwards compatibility.

To the inevitable question: Wont having NS and Non-NS versions be confusing (especially if some are just aliases)? My answer is that it is less confusing than this proposal. There is a simple rule: Things without NS are always the new and preferred methods. Things with NS are there for compatibility and will continue to work the way they do in ObjectiveC (even if you have to import “NSFoundation” to get them instead of just “Foundation")

I think that this approach ends up with confusion as well. Maybe we end up with UserDefaults and NSUserDefaults? One is written in Swift and other is not, but what difference would that make to the caller? Swift itself is not written completely in Swift. Instead, let’s have one UserDefaults that has an API appropriate for Swift. You’ve seen some of that already with changes to the names of its methods (https://github.com/apple/swift/blob/master/apinotes/Foundation.apinotes#L575 as one example, which takes advantage of overloading to simplify the API).

Side Note: I would also REALLY like to see a swift native improvement on NSAttributedString with native literal support.

NSAttributedString was part of the value types proposal at the beginning but deferred for a few practical reasons. One reason is that I want additional existential support in the language first. AttributedString has the concept of a “longest effective run”, which is calculated by checking for equality between attributes. Attributed string should allow for AnyEquatableAndCopyable members of its attribute dictionary. A second problem is that the entire Cocoa text system (and hundreds of higher level APIs) are based on top of the NSString Index concept, which is hidden behind the unicodeScalar view of Swift.String. I would like a more unified story of how these two can interoperate before we revamp the base type.

Both of these are solvable, but they require time to collaborate between teams to decide what the right platform-wide approach is. We’ll do it, but it will not happen immediately.

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.

I would be curious to hear about your explorations (either in another thread or offlist)

I have written a couple of experimental versions of an improved Coding system for Swift. The key idea is to use closures to allow coding of arbitrarily complex nested types (e.g an array of tuples of Dictionaries: [(String, [String:Int])] ). It works pretty well, but unfortunately currently taxes the compiler to the point where it randomly crashes during compilation. I am waiting for the new generics stuff to come online before I explore further, since I believe that will dramatically simplify the code.

The other idea which I would like to see replicated is that it codes to an intermediate format which can then be transformed to/from binary data, XML, BSON (JSON + some representation for Binary Data) or some other format...

It also interoperates very well with existing NSCoding classes, which is an important feature.

Thanks,
Jon

One thing to think about here is what the role of NSCoding is in the first place. It was designed to support archiving of UI objects to nib files. It has been pressed into service for all kinds of other interesting tasks since; UI state restoration, document formats, and IPC wire protocol, to name a few. It may be worthwhile to decide if these are really all the same use case or not. I’m honestly not sure yet. Some of these are very focused on dynamic behavior (that is, the object graph is not known in advance). For some, custom object types are really important (NSXPC takes full advantage of this, and is basically its reason for existence over the raw libxpc API). For others it is not (a raw document file of one million double values). Some of these have different performance requirements than others (archiving fast is important to IPC but unarchiving fast is important to loading nib files).

- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Fabian) #6

Are there any current plans on developing an AttributedString Swift overlay?


(Tony Parker) #7

Yes. It's something we know that we need and are continuing to evaluate. In terms of existential support, for example, Doug's recent opaque return type proposal may be just what we need.