Then again, Data bridges to NSData which bridges to DispatchData, meaning that it may contain multiple non-contiguous buffers (on Obj-C platforms). I’m not sure if a standard-library data type would want that.
That said, the impedance mismatch between Data and DispatchData in Swift is really, really annoying whenever you run in to it.
Actually anything can be bridged to Obj-C classes. Just run as Any as AnyObject on any random instance even on your Foo struct. However I find this behavior really annoying. There is a deffered proposal written by Joe Groff I believe that intended to remove implicit bridging from dynamic casts.
Ahh, this is what I didn’t understand. I sort of get how it works now.
Hmm. Then I guess if Data were to be implemented in Swift whilst mantaining bridge compatibility with ObjC’s NSData, then why not? Maybe it can’t be part of the Stdlib for other reasons, but probably not this one.
Well to me stdlib should only have simple types from which you‘d build the rest. Data is simply an array of bytes that can be read from or written to file and contains some other convenience methonds. Even if Data feels lightweight, I think it does not fit into stdlib, where on the other hand something like OrderedSet/SortedSet could fit into stdlib IMHO.
Furthermore Data would require types like Url which clearly do not fit into stdlib.
Actually, reflecting on all the bridging we already have, I changed my own mind - I don’t think an underlying DispatchData should be a problem. Right now, you could write your own, wild NSArray or NSString subclass and Swift will bridge it.
The great thing is that if we lower Data to the stdlib, DispatchData can go away entirely at the Swift level.
why could those not be extensions provided by Foundation?
Data is about more than file I/O; it’s an RAII wrapper for memory. Currently we only have plain alloc/free in the standard library.
The reason I brought up bridging is because I had the idea, a long time ago, that Data should really live in Dispatch and Foundation should just provide a typealias Data = DispatchData, because I wanted to unify the two.
If you take a look at the top of tree Data implementation, you’ll see that by using NSData as the backing for struct Data, we were able to make some gigantic performance improvements. One big reason is because the vast majority of NSData/Data you find is contiguous, but dispatch data is not.
In fact, I really believe that in the long term, this fundamental difference between the two should really be the key reason to use one over the other. I’m hoping to evolve the API in that direction (e.g., subscripting should not be a thing on dispatch data because libdispatch provides no O(1) way to get at an offset).
So maybe it’s not so relevant to this idea. We could still move Data to the stdlib and worry about unifying those types (or not) another day.
I would definitely support Data in the standard library!
Indeed I believe Data should have similiar design to Array. Now, we don’t have DataSlice or ContagiousData types as we have for arrays. These types are more meaningfull and can be introduced when we move Data into stdlib.
You misunderstand what he said; he’s talking about the Swift overlay for Obj-C compatible platforms (which lives in the compiler repository on GitHub - here), and the swift-corelibs-foundation Git repository which applies to all other platforms (here).
Currently they have to be manually kept in-sync; he’s saying that it would be good if the Obj-C overlay could get away from being inside the compiler project and live with the other platforms, but that requires a more-stable compiler.