[swift-evolution] Standard library 'Data' type pre-proposal

[Jeremy Pereira]

I think there is a typo on the initialiser from a hex tuple string. The external name of the first parameter should not be `base64EncodedString`. In fact, I’m not sure why base64String and hexTupleString aren’t OK for the external name of first parameter of those initialisers.



> On 12 May 2016, at 11:42, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello developers,
> 
> After considering everyone's feedback, I decided to completely rewrite my trial balloon proposal (https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md).
> 
> In short, much of the API interface has been extracted into a `Data` protocol; two concrete implementations (one exploiting Swift 3's conditional protocol conformances) can be used for different purposes. The API should properly model data objects using both contiguous and non-contiguous backing stores.
> 
> Further thoughts, opinions, criticism, or just ideas as to what a great `Data` type would be capable of doing are much appreciated. Thanks again!
> 
> Best,
> Austin
> 
> 
>> On May 11, 2016, at 11:29 AM, Austin Zheng <austinzheng at gmail.com> wrote:
>> 
>> Hi Dmitri,
>> 
>> Thanks for the feedback! I'm glad that we could start a conversation on the lists, and happy to see people offering their unvarnished opinions.
>> 
>> I think conditional conformances upon Array<UInt8> is definitely an avenue worth exploring. I'm not sure what the performance implications are - Zach brought up use cases in which the ability for a data type to be backed by non-contiguous storage was important. More generally, I wanted to open up discussion as to what people wanted from a native Data type.
>> 
>> It seems like a DataProtocol-like protocol may be a good idea. Array<UInt8> could conform through conditional conformances to provide an implementation for people wanting a simple contiguous buffer that could be punned to an array or other linear collection, while a more robust dispatch_data_t-like conforming Swift stdlib type could be provided for more demanding use cases. This actually seems to be a good fit - if you only care about a data buffer as an arbitrary collection of bytes, the abstract protocol interface gives you flexibility, while if you have requirements that require a specific representation of data in memory you should use a concrete type.
>> 
>> Best,
>> Austin
>> 
>> 
>> 
>> On Wed, May 11, 2016 at 11:01 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> On Wed, May 11, 2016 at 2:37 AM, Austin Zheng via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> > Hello swift-evolution,
>> >
>> > I've been thinking about a standard library 'Data' type for a while,
>> > analogous to NSData in the same way Swift's Arrays and Dictionaries are
>> > analogous to NSArrays and NSDictionaries. A first-class container for binary
>> > data that is available to every Swift user, conforms to Swift semantics, and
>> > is safer and easier to work with than UnsafeBufferPointer seems like a
>> > natural fit for the standard library.
>> 
>> Hi Austin,
>> 
>> This is an interesting territory!
>> 
>> One thing that I would like to suggest for us to consider is
>> justifying why Data needs to be a separate type from Array<Int8> and
>> Array<UInt8>.  We can add conditional extensions to Array of Int8 and
>> UInt8 if we find that existing NSData/dispatch_data_t usecases need a
>> few special APIs that won't make sense on arrays in general.
>> 
>> For example, something that I would imagine people want to do with
>> "data buffer" types is being able to make an unaligned or type punned
>> load or store.  For example, in Java, this is one of the primary
>> usecases for a type similar in spirit, java.nio.ByteBuffer
>> (https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html).
>> 
>> Another usecase that is a crossover between Array and Data, allow
>> Array to (unsafely) adopt ownership of an existing initialized unsafe
>> buffer pointer.  We had quite a few requests for this.  Do you think
>> this is an interesting usecase?  Does it overlap with this discussion?
>> 
>> Dmitri
>> 
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution