on Fri Jul 22 2016, Bob Wilson <[email protected]> wrote: > It is not so clear what to do about SR-1956. (Charlie and I had some > comments on this in https://github.com/apple/swift-evolution/pull/437 > <https://github.com/apple/swift-evolution/pull/437>.) Jordan raised > the objection that when using withUnsafePointer with a global, there > is an expectation that you’ll get the same address every > time. Removing inout would cause the argument to be passed by value > and the address would refer to a copy. Dmitri agreed that this could > be a problem. On the other hand, if you don’t care about the address, > or if you’re not using a value type, it would indeed be convenient to > have a version of withUnsafePointer that does not require an inout > argument. > > Option 1: Keep inout (not addressing SR-1956). In this case, there’s > no reason to have both withUnsafePointer and > withUnsafeMutablePointer. If you want to call a function that expects > an UnsafePointer, you can give it an UnsafeMutablePointer and there > will be an implicit conversion to make it work. I discussed this with > Apple’s stdlib team and they recommended that if we have only one > function we use the shorter name “withUnsafePointer” and have it use > an UnsafeMutablePointer.
Very much in favor of Option 1. > > Option 2: Fix SR-1956 and have two functions, one with inout and the > other not. This would address the inconvenience of not being able to > use withUnsafePointer with immutable values, while still supporting > the existing behavior. The question then would be what to call these > two functions. We do not need to support new use-cases in this release, and this would be unsatisfying because the “address of a global” property that Jordan argued for would not hold for the immutable version. > - Option 2a. Combine the two existing functions as in Option 1 and use > a new name for the non-inout version, e.g., > withUnsafePointer(toCopyOf:), so that it won’t be confused with the > old function. (That particular name doesn’t work very well when > dealing with references to objects, since the object itself would not > be copied. I haven’t yet come up with a better name, though.) One > advantage of this approach is that we would not need to rush the new > function into Swift 3 since it would be an additive change. Not rushing that into Swift 3 is the same as Option 1. > - Option 2b. Switch to use withUnsafeMutablePointer for all the cases > where you care about the getting the same address. Change > withUnsafePointer to be the non-inout version. Charlie suggested that > we could have the migrator convert all existing uses on > withUnsafePointer in Swift 2 code to use withUnsafeMutablePointer in > Swift 3, but I’m not sure how well that would work. That's exactly the same outcome, with respect to the language/library surface, as Option 2 AFAICT. Can we simplify this list of options? -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
