This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore to the Objective C overlay. The reason to do this is that ideally StdlibCore would not have any code specific to ObjC in it. This is a small step that we can take in this direction by moving the public API of AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this would be done is that the implementation for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would add an underscore to make that API private to the standard library. Then inside the ObjC overlay, we would create a typealias to the internal API with the non-underscored name (i.e. make the typealias the public API). Then at a later point in time we can move the implementation. The reason why I am not proposing to move the implementation today is that there are dependencies in Array/Hashed Collections on AutoreleasingUnsafeMutablePointer. Moving that code is a larger project that is preconditioned on this proposal going in first as an incremental step.
This is a proposal to move AutoreleasingUnsafeMutablePointer from
StdlibCore to the Objective C overlay. The reason to do this is that
ideally StdlibCore would not have any code specific to ObjC in
it. This is a small step that we can take in this direction by moving
the public API of AutoreleasingUnsafeMutablePointer to the ObjC
overlay.
+1
To avoid confusion among reviewers, I feel I need to point out that
everything below this point is implementation detail that IMO has no
relevance to the evolution list.
The way that this would be done is that the implementation
for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but
we would add an underscore to make that API private to the standard
library. Then inside the ObjC overlay, we would create a typealias to
the internal API with the non-underscored name (i.e. make the
typealias the public API). Then at a later point in time we can move
the implementation. The reason why I am not proposing to move the
implementation today is that there are dependencies in Array/Hashed
Collections on AutoreleasingUnsafeMutablePointer. Moving that code is
a larger project that is preconditioned on this proposal going in
first as an incremental step.
I am not confident that we will ever be able to move that code, but as I
said before, that's really irrelevant here. Let's do it!
···
on Thu Jul 21 2016, Michael Gottesman <swift-evolution@swift.org> wrote:
On Jul 21, 2016, at 10:02 AM, Michael Gottesman via swift-evolution <swift-evolution@swift.org> wrote:
Hello everyone.
This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore to the Objective C overlay. The reason to do this is that ideally StdlibCore would not have any code specific to ObjC in it. This is a small step that we can take in this direction by moving the public API of AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this would be done is that the implementation for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would add an underscore to make that API private to the standard library. Then inside the ObjC overlay, we would create a typealias to the internal API with the non-underscored name (i.e. make the typealias the public API). Then at a later point in time we can move the implementation. The reason why I am not proposing to move the implementation today is that there are dependencies in Array/Hashed Collections on AutoreleasingUnsafeMutablePointer. Moving that code is a larger project that is preconditioned on this proposal going in first as an incremental step.
I agree on principle for moving it out of stdlib, but what's the Objective-C overlay?
Félix
···
Le 21 juil. 2016 à 10:02:46, Michael Gottesman via swift-evolution <swift-evolution@swift.org> a écrit :
Hello everyone.
This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore to the Objective C overlay. The reason to do this is that ideally StdlibCore would not have any code specific to ObjC in it. This is a small step that we can take in this direction by moving the public API of AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this would be done is that the implementation for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would add an underscore to make that API private to the standard library. Then inside the ObjC overlay, we would create a typealias to the internal API with the non-underscored name (i.e. make the typealias the public API). Then at a later point in time we can move the implementation. The reason why I am not proposing to move the implementation today is that there are dependencies in Array/Hashed Collections on AutoreleasingUnsafeMutablePointer. Moving that code is a larger project that is preconditioned on this proposal going in first as an incremental step.
If you want to move APIs which aren't cross-platform out of stdlib, should there be a similar proposal for the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable protocol?
On 21 Jul 2016, at 18:02, Michael Gottesman wrote:
This is a proposal to move AutoreleasingUnsafeMutablePointer from StdlibCore to the Objective C overlay. The reason to do this is that ideally StdlibCore would not have any code specific to ObjC in it. This is a small step that we can take in this direction by moving the public API of AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this would be done is that the implementation for AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would add an underscore to make that API private to the standard library. Then inside the ObjC overlay, we would create a typealias to the internal API with the non-underscored name (i.e. make the typealias the public API). Then at a later point in time we can move the implementation. The reason why I am not proposing to move the implementation today is that there are dependencies in Array/Hashed Collections on AutoreleasingUnsafeMutablePointer. Moving that code is a larger project that is preconditioned on this proposal going in first as an incremental step.
Complaining about an API that 99% of users won't ever have to touch and
exists to facilitate NS/CF interop is a bit precious, to be charitable.
···
On Thu, Jul 21, 2016 at 11:19 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:
> On Jul 21, 2016, at 10:02 AM, Michael Gottesman via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Hello everyone.
>
> This is a proposal to move AutoreleasingUnsafeMutablePointer from
StdlibCore to the Objective C overlay. The reason to do this is that
ideally StdlibCore would not have any code specific to ObjC in it. This is
a small step that we can take in this direction by moving the public API of
AutoreleasingUnsafeMutablePointer to the ObjC overlay. The way that this
would be done is that the implementation for
AutoreleasingUnsafeMutablePointer would remain in StdlibCore, but we would
add an underscore to make that API private to the standard library. Then
inside the ObjC overlay, we would create a typealias to the internal API
with the non-underscored name (i.e. make the typealias the public API).
Then at a later point in time we can move the implementation. The reason
why I am not proposing to move the implementation today is that there are
dependencies in Array/Hashed Collections on
AutoreleasingUnsafeMutablePointer. Moving that code is a larger project
that is preconditioned on this proposal going in first as an incremental
step.
>
> Thoughts, flames, etc?
That is a good question! We don't have an obvious existing module into
which to move them, though, do we?
···
on Fri Jul 22 2016, Ben Rimmington <swift-evolution@swift.org> wrote:
On 21 Jul 2016, at 18:02, Michael Gottesman wrote:
This is a proposal to move AutoreleasingUnsafeMutablePointer from
StdlibCore to the Objective C overlay. The reason to do this is that
ideally StdlibCore would not have any code specific to ObjC in
it. This is a small step that we can take in this direction by
moving the public API of AutoreleasingUnsafeMutablePointer to the
ObjC overlay. The way that this would be done is that the
implementation for AutoreleasingUnsafeMutablePointer would remain in
StdlibCore, but we would add an underscore to make that API private
to the standard library. Then inside the ObjC overlay, we would
create a typealias to the internal API with the non-underscored name
(i.e. make the typealias the public API). Then at a later point in
time we can move the implementation. The reason why I am not
proposing to move the implementation today is that there are
dependencies in Array/Hashed Collections on
AutoreleasingUnsafeMutablePointer. Moving that code is a larger
project that is preconditioned on this proposal going in first as an
incremental step.
If you want to move APIs which aren't cross-platform out of stdlib,
should there be a similar proposal for the PlaygroundQuickLook enum
and CustomPlaygroundQuickLookable protocol?
This is a proposal to move AutoreleasingUnsafeMutablePointer from
StdlibCore to the Objective C overlay. The reason to do this is that
ideally StdlibCore would not have any code specific to ObjC in
it. This is a small step that we can take in this direction by
moving the public API of AutoreleasingUnsafeMutablePointer to the
ObjC overlay. The way that this would be done is that the
implementation for AutoreleasingUnsafeMutablePointer would remain in
StdlibCore, but we would add an underscore to make that API private
to the standard library. Then inside the ObjC overlay, we would
create a typealias to the internal API with the non-underscored name
(i.e. make the typealias the public API). Then at a later point in
time we can move the implementation. The reason why I am not
proposing to move the implementation today is that there are
dependencies in Array/Hashed Collections on
AutoreleasingUnsafeMutablePointer. Moving that code is a larger
project that is preconditioned on this proposal going in first as an
incremental step.
If you want to move APIs which aren't cross-platform out of stdlib,
should there be a similar proposal for the PlaygroundQuickLook enum
and CustomPlaygroundQuickLookable protocol?
That is a good question! We don't have an obvious existing module into
which to move them, though, do we?
This is just an incremental proposal. The playground work should be in a different proposal so we keep this proposal focused.
Michael
···
On Jul 22, 2016, at 11:42 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jul 22 2016, Ben Rimmington <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 21 Jul 2016, at 18:02, Michael Gottesman wrote:
This philosophy appeals to me, especially when considering Swift as a
cross-platform language. Would you all be open to "new module" proposals?
Would that be internal or through Swift Evolution? I'm thinking also of
the discussion about creating a Swift native Math module w/ JordanR and
Steve C for things that don't belong in the stdlib but would be nice to have around,
sanctioned native modules.
As for PlaygroundSupport, how does that tie into stdlib? I thought it was its own
thing, separate from stdlib. Wouldn't both quick look and lookable belong there?
-- E
···
On Jul 22, 2016, at 12:42 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Fri Jul 22 2016, Ben Rimmington <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 21 Jul 2016, at 18:02, Michael Gottesman wrote:
This is a proposal to move AutoreleasingUnsafeMutablePointer from
StdlibCore to the Objective C overlay. The reason to do this is that
ideally StdlibCore would not have any code specific to ObjC in
it. This is a small step that we can take in this direction by
moving the public API of AutoreleasingUnsafeMutablePointer to the
ObjC overlay. The way that this would be done is that the
implementation for AutoreleasingUnsafeMutablePointer would remain in
StdlibCore, but we would add an underscore to make that API private
to the standard library. Then inside the ObjC overlay, we would
create a typealias to the internal API with the non-underscored name
(i.e. make the typealias the public API). Then at a later point in
time we can move the implementation. The reason why I am not
proposing to move the implementation today is that there are
dependencies in Array/Hashed Collections on
AutoreleasingUnsafeMutablePointer. Moving that code is a larger
project that is preconditioned on this proposal going in first as an
incremental step.
If you want to move APIs which aren't cross-platform out of stdlib,
should there be a similar proposal for the PlaygroundQuickLook enum
and CustomPlaygroundQuickLookable protocol?
This is a proposal to move AutoreleasingUnsafeMutablePointer from
StdlibCore to the Objective C overlay. The reason to do this is that
ideally StdlibCore would not have any code specific to ObjC in
it. This is a small step that we can take in this direction by
moving the public API of AutoreleasingUnsafeMutablePointer to the
ObjC overlay. The way that this would be done is that the
implementation for AutoreleasingUnsafeMutablePointer would remain in
StdlibCore, but we would add an underscore to make that API private
to the standard library. Then inside the ObjC overlay, we would
create a typealias to the internal API with the non-underscored name
(i.e. make the typealias the public API). Then at a later point in
time we can move the implementation. The reason why I am not
proposing to move the implementation today is that there are
dependencies in Array/Hashed Collections on
AutoreleasingUnsafeMutablePointer. Moving that code is a larger
project that is preconditioned on this proposal going in first as an
incremental step.
If you want to move APIs which aren't cross-platform out of stdlib,
should there be a similar proposal for the PlaygroundQuickLook enum
and CustomPlaygroundQuickLookable protocol?
That is a good question! We don't have an obvious existing module into
which to move them, though, do we?
This is just an incremental proposal. The playground work should be in
a different proposal so we keep this proposal focused.
+1
···
on Fri Jul 22 2016, Michael Gottesman <swift-evolution@swift.org> wrote:
On Jul 22, 2016, at 11:42 AM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
on Fri Jul 22 2016, Ben Rimmington > >> <swift-evolution@swift.org >> <mailto:swift-evolution@swift.org>> >> wrote:
On 21 Jul 2016, at 18:02, Michael Gottesman wrote: