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.
Dmitri
···
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.
+1 from the proposal author, although since it went through community
review that doesn't make me an authority ;)
···
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.
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).
Russ
···
On May 11, 2016, at 4:50 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev > <swift-dev@swift.org> wrote:
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
···
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 <gribozavr@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).
Ah good old “same-type requirement makes generic parameter non-generic” :)
I see what the objection is and it makes sense to me. I’ll implement it as closely as I can to the spirit of the proposal.
Russ
···
On May 11, 2016, at 10:18 PM, Chris Lattner <clattner@apple.com> wrote:
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.
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
···
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 <gribozavr@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!
I’d suggest wrapping up this proposal as specified. When/if Andy’s proposal goes through, we can move these APIs over. This proposal is progress from the status quo, perfection is the enemy of good after all.
-Chris
···
On May 12, 2016, at 9:16 PM, Russ Bishop <xenadu@gmail.com> wrote:
On May 12, 2016, at 8:33 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
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
Fair enough; I can hold off on this branch until then.
That’s the right call. For the record, I suggested moving to/fromOpaque to initializers during the community review and it was immediately shot down by Jordan because it’s incorrect for UnsafePointer<T> where T is non-Void.
-Andy
···
On May 12, 2016, at 9:57 PM, Chris Lattner via swift-dev <swift-dev@swift.org> wrote:
On May 12, 2016, at 9:16 PM, Russ Bishop <xenadu@gmail.com <mailto:xenadu@gmail.com>> wrote:
On May 12, 2016, at 8:33 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
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
Fair enough; I can hold off on this branch until then.
I’d suggest wrapping up this proposal as specified. When/if Andy’s proposal goes through, we can move these APIs over. This proposal is progress from the status quo, perfection is the enemy of good after all.