> On Dec 15, 2015, at 11:51 PM, Kevin Ballard <ke...@sb.org> wrote: > > On Tue, Dec 15, 2015, at 11:25 PM, Dave Abrahams wrote: >> >>> On Dec 15, 2015, at 6:46 PM, Kevin Ballard <ke...@sb.org> wrote: >>> >>> On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote: >>>> >>>>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev >>>>> <swift-dev@swift.org> wrote: >>>>> >>>>> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote: >>>>>> >>>>>> Yeah, it seems to me like a reasonable refinement for >>>>>> 'withUnsafePointer' to take an immutable parameter. Since this is a >>>>>> stdlib API change, you should suggest that on swift-evolution. >>>>> >>>>> A change like that is going to break any code that relies on the inout >>>>> optimization (where it uses call-by-reference instead of copy-in copy-out >>>>> when possible). Yes, such code is in violation of Swift semantics today, >>>>> but it does work. >>>> >>>> Two questions: >>>> >>>> 1. Don’t we want a withUnsafeMutablePointer for the mutating cases (where >>>> the inout optimization can take effect) anyway? >>> >>> I'm thinking here of cases like passing a context pointer to KVO. You're >>> not actually mutating it, you just need a pointer that's the same every >>> time you call the code. >> >> Well, it is not possible to code a version of withUnsafePointer that makes >> that guarantee in Swift. > > Yeah but we want to move in the direction of making that more reliable, not > less.
I am not sure I agree with you. I would defer to John McCall on this one, but my understanding is that it's an explicit non-goal to make that guarantee. > I forget who but someone said in another thread that global variables can be > reliably passed by-ref to functions that take pointers already (even though > the Swift documentation does not guarantee this). > > Come to think of it, what's the actual use-case for withUnsafePointer()? I'm not sure we still have one that isn't covered by &x; that's my point. > If a value is mutable, you can already use &x or withUnsafeMutablePointer(), > and if it's immutable, you can't call withUnsafePointer() today anyway. The > proposed change would just make withUnsafePointer() into the equivalent of > `var x = value; callSomethingWith(&x)`. The only reason to really want a > withUnsafePointer() function is if it can give you an UnsafePointer to an > immutable value without copying it, but we can't do that. I'm inclined to say > we should just get rid of withUnsafePointer() entirely, at least until such > time as Swift has a way to pass immutable values by-ref. I'm inclined to agree. Proposal? _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
