<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello developers,<div class=""><br class=""></div><div class="">After considering everyone's feedback, I decided to completely rewrite my trial balloon proposal (<a href="https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md" class="">https://github.com/austinzheng/swift-evolution/blob/d2/proposals/XXXX-stdlib-data.md</a>).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Further thoughts, opinions, criticism, or just ideas as to what a great `Data` type would be capable of doing are much appreciated. Thanks again!</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 11, 2016, at 11:29 AM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Dmitri,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, May 11, 2016 at 11:01 AM, Dmitri Gribenko <span dir="ltr" class=""><<a href="mailto:gribozavr@gmail.com" target="_blank" class="">gribozavr@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, May 11, 2016 at 2:37 AM, Austin Zheng via swift-evolution<br class="">
<<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
> Hello swift-evolution,<br class="">
><br class="">
> I've been thinking about a standard library 'Data' type for a while,<br class="">
> analogous to NSData in the same way Swift's Arrays and Dictionaries are<br class="">
> analogous to NSArrays and NSDictionaries. A first-class container for binary<br class="">
> data that is available to every Swift user, conforms to Swift semantics, and<br class="">
> is safer and easier to work with than UnsafeBufferPointer seems like a<br class="">
> natural fit for the standard library.<br class="">
<br class="">
</span>Hi Austin,<br class="">
<br class="">
This is an interesting territory!<br class="">
<br class="">
One thing that I would like to suggest for us to consider is<br class="">
justifying why Data needs to be a separate type from Array<Int8> and<br class="">
Array<UInt8>. We can add conditional extensions to Array of Int8 and<br class="">
UInt8 if we find that existing NSData/dispatch_data_t usecases need a<br class="">
few special APIs that won't make sense on arrays in general.<br class="">
<br class="">
For example, something that I would imagine people want to do with<br class="">
"data buffer" types is being able to make an unaligned or type punned<br class="">
load or store. For example, in Java, this is one of the primary<br class="">
usecases for a type similar in spirit, java.nio.ByteBuffer<br class="">
(<a href="https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html" rel="noreferrer" target="_blank" class="">https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html</a>).<br class="">
<br class="">
Another usecase that is a crossover between Array and Data, allow<br class="">
Array to (unsafely) adopt ownership of an existing initialized unsafe<br class="">
buffer pointer. We had quite a few requests for this. Do you think<br class="">
this is an interesting usecase? Does it overlap with this discussion?<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
Dmitri<br class="">
<br class="">
--<br class="">
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br class="">
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>>*/<br class="">
</font></span></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>