[swift-evolution] Proposal: [stdlib] Remove withUnsafe[Mutable]Pointer[s]()

[Jacob Bandes-Storch]

Is there a reason that this couldn't be made to work?

    let ptr: UnsafePointer<Void> = &x

Jacob

On Wed, Dec 16, 2015 at 2:16 PM, Michael Gottesman via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Dec 16, 2015, at 4:07 PM, Michael Gottesman via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On Dec 16, 2015, at 2:22 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> >>
> >>
> >>> On Dec 16, 2015, at 11:54 AM, Michael Gottesman via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>>>
> >>>> On Dec 16, 2015, at 1:49 PM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>>
> >>>> Another replacement for withUnsafe[Mutable]Pointer is declaring a
> nested function of the appropriate type (this is equivalent to the
> anonymous closure, but perhaps more readable):
> >>>>
> >>>> func foo(ptr: UnsafePointer<Int>) {
> >>>> // ...
> >>>> }
> >>>> foo(&x)
> >>>>
> >>>> -Kevin
> >>>>
> >>>> On Wed, Dec 16, 2015, at 11:38 AM, Kevin Ballard wrote:
> >>>>> # Introduction
> >>>>>
> >>>>> The stdlib provides functions withUnsafePointer() and
> withUnsafeMutablePointer() (and plural variants) that take an inout
> reference and call a block with the UnsafePointer/UnsafeMutablePointer
> created from the reference.
> >>>>>
> >>>>> # Problem
> >>>>>
> >>>>> withUnsafePointer() can only be used with mutable variables, because
> those are the only things that can be used with inout &refs. Both functions
> are also fairly useless, as &x refs can be passed directly to functions
> taking an UnsafePointer or UnsafeMutablePointer. The existence of the
> functions mostly just causes people to think they're necessary when they're
> not. The provide no functionality that passing &x refs directly to the
> functions taking a pointer doesn't already fulfill.
> >>>>>
> >>>>> # Solution
> >>>>>
> >>>>> Remove the functions from the stdlib. The Swift Book should also be
> updated to talk about passing an &x ref to a function that takes an
> UnsafePointer or UnsafeMutablePointer (but of course changes to the book
> are not covered by the open-source project). Most uses of these functions
> can probably be replaced with a &x ref directly. If any can't, they could
> be replaced with the following equivalent expressions:
> >>>>>
> >>>>> { (ptr: UnsafePointer<Int>) in
> >>>>> // ...
> >>>>> }(&x)
> >>>>>
> >>>>> or:
> >>>>>
> >>>>> withExtendedLifetime(&x) { (ptr: UnsafePointer<Int>) in
> >>>>> // ...
> >>>>> }
> >>>
> >>> One thing to keep in mind here is that with*Pointer and friends is
> also meant to enable one to work around issues with the optimizer if they
> come up in a convenient manner. I.e. imagine if one is attempting to
> process an image using a 5d array and for whatever reason, you are not
> getting the performance you need. Hopefully you would file a bug report and
> then use with*Pointer for your image processing loop.
> >>>
> >>> My fear about withExtendedLifetime is that the name is a misnomer. You
> are not extending the lifetime.
> >>
> >> What makes you say that?
> >
> > Let me be more specific.
> >
> > My issue with the name 'withExtendedLifetime' is that it is suggestive
> that the lifetime of &x is being extended in a way that is different from
> if one just passed off &x to any old function. In reality though, nothing
> special is happening here implying that the name is misleading. A better
> name IMO would be something that drops any such implication.
>
> For example, we could just use 'with' (something that has been suggested
> for this use case in various blog posts). I.e.:
>
> with(&x) { (ptr: UnsafePointer<Int>) in
>    ...
> }
>
> Michael
>
> >
> > Michael
> >
> >>
> >> If in fact it is true, shouldn't you file a bug report?
> >>
> >> -Dave
> >>
> >>
> >>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/ffaef215/attachment.html>