[swift-evolution] [Draft] UnsafeRawPointer API
Andrew Trick
atrick at apple.com
Mon Jun 27 17:18:02 CDT 2016
> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>
> think you mean T.Type, not T.self, because this looks like a declaration.
>>
>> To evaluate, you have to look at the use-site:
>>
>> let p = UnsafePointer(r, to: Int.self)
>>
>> I don't find “to” to be descriptive enough. Maybe
>
> toType
>
>>
>> let p = UnsafePointer(r, pointee: Int.self)
>
> I find pointee a total aberation :)
>
>>
>> is better. But I hate that the language doesn't give us a way to say
>> “don't deduce generic parameters here.” This is the only syntax that
>> feels right, IMO:
>>
>> let p = UnsafePointer<Int>(r)
>>
>>> Option (3) UnsafeRawPointer.unsafeCast<T>(to: T.Type) ->
>>> UnsafePointer<T>
>>
>> r.unsafeCast(to: Int.self)
>>
>> I don't see adding “unsafe” to the name of the operation as adding
>> anything. It isn't any more unsafe than other UnsafeRawPointer
>> operations.
>
> It is unsafe in the sense that there are no guarantees that it is a sensible thing to do. I guess that means it is more 'noguaranteeexplicitorimpliedapplied' in the sense that it will like mechanically work, even if it produce an aberation as a result
>
>> Also, it reads like we're casting the raw pointer to an
>> Int, rather than to an UnsafePointer<Int>.
>
> Really good one... But then instead of 'to' or 'pointee', something along the lines of 'wrappedType', which lookes a little less balerina-ish than pointee.....
>
Any gripes about this syntax?
let ptrB = UnsafeRawPointer(ptrA).cast(to: UnsafePointer<B>.Type)
It meets the goal of being perfectly explicit. We can add convenience APIs for certain cases later.
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/9c02f493/attachment.html>
More information about the swift-evolution
mailing list