[swift-users] Why does withUnsafePointer(to:) require a var argument?
alblue at apple.com
Thu Apr 27 03:48:09 CDT 2017
> On 27 Apr 2017, at 09:41, Rien via swift-users <swift-users at swift.org> wrote:
>> On 27 Apr 2017, at 09:54, Rick Mann <rmann at latencyzero.com> wrote:
>>> On Apr 26, 2017, at 23:37 , Rien via swift-users <swift-users at swift.org> wrote:
>>> 1) When you obtain a pointer, it can no longer be ensured by the compiler that you won’t write to it.
>>> 2) A ‘let’ variable (constant) allows way more optimizations than a ‘var’. I would not be surprised if the majority of ‘let’ constants never see any memory allocation at all.
>> In my case, it's a field in a struct that's allocated elsewhere, and most certainly exists, and is passed as a parameter, so it's 'let'. I really want to be able to say "I promise I won't write to this", which seems reasonable if the language is willing to give me an unsafe pointer in the first place.
> IIRC this is the reason for the mutable and non-mutable version of the pointer. With the non-mutable pointer you cannot write to the pointee.
> (At least not without some additional code)
> But it is another step entirely to then allow a let assignment to be used as the pointee. I assume the Swift team decided to keep things simple and not allow let’s to be used as pointee’s. It could probably be done in theory, but I imagine that to be a nightmare case for compiler writers...
The let constant may not even be stored in a single place; if it's known to be constant it can be in-lined at the point of use and potentially unpacked and dead code elimination throw away the unused members, for example.
If you want to pass in a let constant into the pointer, you can create a copy of it locally in a local variable and then use that instead. However this will be in the local scope, so the pointer isn't valid after it returns.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-users