> On 27 Apr 2017, at 09:54, Rick Mann <rm...@latencyzero.com> wrote:
> 
>> 
>> On Apr 26, 2017, at 23:37 , Rien via swift-users <swift-users@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...

Regards,
Rien.

> 
> How is the immutable version of withUnsafePointer different from the mutable 
> one? It passes the argument to the closure as a mutable pointer, which must 
> mean something different.
> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - A server for websites build in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 27 Apr 2017, at 08:31, Florent Bruneau via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> Hi Rick,
>>> 
>>> My understanding on this is that withUnsafePointer() requires an inout 
>>> argument because it has to take a reference to the variable in order to be 
>>> able to derive its pointer. The languages requires inout arguments to be 
>>> vars, leading to withUnsafePointer() requiring the passed object to be a 
>>> var.
>>> 
>>> There may be other subtleties I'm not aware of, though.
>>> 
>>>> Le 27 avr. 2017 à 02:42, Rick Mann via swift-users <swift-users@swift.org> 
>>>> a écrit :
>>>> 
>>>> We have withUnsafePointer(to:) and withUnsafeMutablePointer(to:). Why does 
>>>> the first take an inout parameter? The function names imply that the first 
>>>> will not modify the pointer (which I take to mean its contents), and it 
>>>> makes it quite clunky to pass in constant things.
>>>> 
>>>> -- 
>>>> Rick Mann
>>>> rm...@latencyzero.com
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>>> -- 
>>> Florent Bruneau
>>> 
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to