> On Apr 26, 2017, at 23:37 , Rien via swift-users <[email protected]> > 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. 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 >> <[email protected]> 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 <[email protected]> >>> 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 >>> [email protected] >>> >>> >>> _______________________________________________ >>> swift-users mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-users >> >> -- >> Florent Bruneau >> >> _______________________________________________ >> swift-users mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-users > > _______________________________________________ > swift-users mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-users -- Rick Mann [email protected] _______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
