> On May 11, 2016, at 10:18 PM, Chris Lattner via swift-dev > <swift-dev@swift.org> wrote: > > On May 11, 2016, at 8:17 PM, Russ Bishop via swift-dev <swift-dev@swift.org> > wrote: >> >>> On May 11, 2016, at 4:50 PM, Dmitri Gribenko <griboz...@gmail.com> wrote: >>> >>> On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev >>> <swift-dev@swift.org> wrote: >>>> I’m implementing SE-0017 but based on the standard library guidelines I >>>> think Unmanaged should have initializers that take >>>> UnsafePointer/UnsafeMutablePointer and vice-versa which would fit more >>>> naturally with the way other conversions work. >>>> >>>> A later commit already moved toOpaque to be an initializer on >>>> OpaquePointer. I would add convenience initializers to UnsafePointer as >>>> well. >>>> >>>> Any objections to just implementing this as initializers and marking >>>> fromOpaque as deprecated? I’m not sure how strict we should be in sticking >>>> to the proposal. >>> >>> Unmanaged shall be redesigned. We thought about this change, and >>> decided to go for the incremental change as proposed. Bigger changes >>> should be considered as a part of a cohesive Unmanaged redesign. >>> >> >> Why did someone move toOpaque then? It seems like the door was already >> opened there - it isn’t possible to stick to the proposal as approved anyway. >> >> I can certainly move it back but the initializer vs static seems like a >> best-practices and library design issue orthogonal to Unmanaged itself. >> >> >> At the end of the day if the core team still prefers to go with the >> fromOpaque/toOpaque approach I’m happy to implement it (in fact I have both >> implemented locally right now). > > As Dmitri, we specifically discussed this in the core team meeting (I brought > it up :-). The problem is that we really only want the toOpaque() method to > exist on UnsafePointer<Void> and don’t have the ability to model that in the > language yet. When that ability exists, we’ll revise these APIs and many > others. > > Until then, it is best to keep with the spirit of the current design, warts > and all. Thanks for bringing this up!
We might want to wait till we review Andy's UnsafeBytePointer proposal. If we accept that, it will separate UnsafePointer<Void> into its own type. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
