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!

-Chris
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to