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 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()? 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.

-Kevin Ballard
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to