Moving `Data` into standard library from Foundation?

Why Data is not a basic type and not integrated into Standard library as types like String or Array did?

AFAIK Data is implemented in Swift to take advantage of value types’ performance and it’s not dependent to CoreFoundation.

Many cross-platform projects like Swift-NIO had to implement a replicate to maintain consistency between platforms and avoid importing bloated Foundation.

6 Likes

i always thought Array and String are value types for the semantics, not the performance. underneath, both wrap reference types so there is no reference count savings.

1 Like

I think it should be.

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.

2 Likes

Anything that’s bridging with ObjC shouldn’t be part of the Stdlib. The Stdlib should be pure Swift whenever possible, shouldn’t it?

1 Like

String bridges to NSString
Array bridges to NSArray
Set bridges to NSSet
Dictionary bridges to NSDictionary
All swift classes can bridge to NSObject (via the hidden SwiftObject base class)

We’ve got loads of bridging already.

2 Likes

they only bridge if Foundation is imported i thought

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.

Edit:

5 Likes

String, Array and Dictionary are part of StdLib while they provide toll-free bridge to ObjC counterparts when Foundation is imported.

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.

1 Like

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.

2 Likes

It could work like this, but I don‘t think it would be convenient to use then.

String, Array and Dictionary have initilizers from file url which are implemented in Foundation shim.

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.

@Tony_Parker said (this was a long time ago… Jan 2017):

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!

1 Like

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.

Even Tony Parker (SwiftFoundation maintainer) believes we should merge Foundation and Stdlib at some point, so why not?

And about OrderedSet he said in another thread:

I have absolutely nothing against that change, but I have doubts that it will pass the review process.

isn’t SwiftFoundation an (incomplete) pure Swift implementation of Foundation?

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.

5 Likes

+100, it is frustrating that the standard library contains only 'unsafe' ways to use binary data.

2 Likes