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@swift.org> wrote:
> On Dec 16, 2015, at 4:07 PM, Michael Gottesman via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On Dec 16, 2015, at 2:22 PM, Dave Abrahams <dabrahams@apple.com> wrote:
>>
>>
>>> On Dec 16, 2015, at 11:54 AM, Michael Gottesman via swift-evolution < > swift-evolution@swift.org> wrote:
>>>
>>>>
>>>> On Dec 16, 2015, at 1:49 PM, Kevin Ballard via swift-evolution < > swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution