> 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. 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
