I think instead handleMessages should take a Data argument.
The core issue here is that the problem solved here is not a "foundation problem", it is a "stdlib problem". They are superficially similar in that both of them involve an array of bytes but the comparison ends there.
The motivation for Data/NSData is we have a logical collection of bytes. That collection may be contiguous or discontiguous (speaking only of API; I'm unfamiliar with the implementation choice). It may be created from a file or even a URL, from a base64 representation, it may share the underlying memory with other NSData instance or not.
What we are considering here is a *physical* collection of bytes, e.g. a pointer and a length. By definition, they do not share memory with each other (unless they overlap, which is you can find out with public API). By definition, they are contiguous.
Data is the abstraction to choose when you don't care how the memory is laid out. UnsafeBytes is the abstraction to choose when the memory layout is the critical property. e.g., you are bitshifting between the IEEE754 fields to implement fastinvsqrt, or you are converting between sockaddr and sockaddr_in (same type but different sizes).
These are not I/O problems or array problems. They are C pointer problems, where we want to dispense with the traditional Swift abstractions and view the world as C arrays again like it's 1970.
Like all pointer problems in the language, they aren't foundation problems and we should not solve them there, whether we are under time pressure or with all the time in the world. They should be solved where we solve the other pointer problems, which is in the stdlib.
I think instead handleMessages should take a Data argument. The input driver code should be able to use API on Data (or elsewhere, API that returns Data) to populate it with the contents of the file.
The core API in my networking project is fairly similar to this example, and in that case, NSData was not the right choice, because it does not support
Uninitialized arrays
Explicitly managing zero-cost "views" of the underlying memory by creating instances that refer to the same location and sliding the start and end markers
Casting unsafely between arrays of different size
Working with memory regions where the size is not known at compile time but is discovered during a read such as pascal strings or msgpack
These are totally ridiculous additions to the Data API surface. Somebody who wants to load a URL should never see this garbage in their autocomplete. But they are things C programmers frequently do.
···
On September 2, 2016 at 3:34:56 PM, Tony Parker via swift-evolution (swift-evolution@swift.org) wrote: