Hi all, i’ve put out a new revision of the proposal which addresses Michael’s point about dealing with the memorystate APIs along with the allocation and deallocation API. I didn’t really think about fixing the memorystate functions originally, but on closer inspection, they are almost as problematic as the memory allocation API and deserve a closer look.
Here’s a new version of the proposal with revisions <https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06> On Wed, Jul 12, 2017 at 6:46 PM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > I originally thought that would be too many changes for one proposal but > if y’all think it’s a good idea to deal with those functions too I’m happy > to add it to the proposal! > > On Wed, Jul 12, 2017 at 5:07 PM, Michael Ilseman <milse...@apple.com> > wrote: > >> If you’re considering moving allocate/deallocate to Unsafe*BufferPointer, >> then you probably also want to consider doing the same for initialize, >> deinitialize, and various move functions as well. >> >> On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Hi all, I’ve written up a proposal to modify the unsafe pointer API for >> greater consistency, safety, and ease of use. >> >> ~~~ >> >> Swift currently offers two sets of pointer types — singular pointers such >> as UnsafeMutablePointer, and vector (buffer) pointers such as >> UnsafeMutable*Buffer*Pointer. This implies a natural separation of tasks >> the two kinds of pointers are meant to do. For example, buffer pointers >> implement Collection conformance, while singular pointers do not. >> >> However, some aspects of the pointer design contradict these implied >> roles. It is possible to allocate an arbitrary number of instances from a >> type method on a singular pointer, but not from a buffer pointer. The >> result of such an operation returns a singular pointer, even though a >> buffer pointer would be more appropriate to capture the information about >> the *number* of instances allocated. It’s possible to subscript into a >> singular pointer, even though they are not real Collections. Some parts >> of the current design turn UnsafePointers into downright *Dangerous*Pointers, >> leading users to believe that they have allocated or freed memory when in >> fact, they have not. >> >> This proposal seeks to iron out these inconsistencies, and offer a more >> convenient, more sensible, and less bug-prone API for Swift pointers. >> >> <https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06> >> >> ~~~ >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution