[swift-dev] What do to when stdlib guidelines conflict with proposal?

[Joe Groff]

> On May 11, 2016, at 10:18 PM, Chris Lattner via swift-dev <swift-dev at swift.org> wrote:
> 
> On May 11, 2016, at 8:17 PM, Russ Bishop via swift-dev <swift-dev at swift.org> wrote:
>> 
>>> On May 11, 2016, at 4:50 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> 
>>> On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev
>>> <swift-dev at 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