[swift-evolution] Proposal: Add replace(_:with:) function to the stdlib

[Dave Abrahams]

> On Dec 13, 2015, at 2:21 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> A function I find myself defining in a lot of my projects looks like the following:
>  
> /// Replace the value of `a` with `b` and return the old value.
> public func replace<T>(inout a: T, with b: T) -> T {
>     var value = b
>     swap(&a, &value)
>     return value
> }
>  
> This is a pretty simple function, and useful in a wide variety of circumstances, so I'd love to get it into the standard library. It doesn't actually enable any behavior that wasn't previously possible, but it does shrink some common code patterns, and I find the shorter code easier to read.
>  
> An example of a place where I use it often is in replacing an optional property with a new value (or with nil) and cleaning up the previous value. Assuming a property like
>  
> var task: NSURLSessionTask?
>  
> This replaces
>  
> if let task = self.task {
>     task.cancel()
> }
> task = nil
>  
> with
>  
> replace(&task, with: nil)?.cancel()
>  
> Or sometimes I use it like
>  
> if let value = replace(&prop, with: newValue) {
>     // multi-line cleanup
> }
>  
> This is particularly nice if it's a COW value that I want to mutate, as it means I don't have to worry about getting unwanted copies due to the property still holding the old value while I muck with it.

This is a generalization of the postincrement pattern (mutate a value and return the original) and given that we're moving away from that I'm not sure it's something we want to enshrine in the standard library. That said, here's a question: looking at your use cases, how many of them are using something other than nil (or some moral equivalent) as the second argument?  If this is effectively a non-destructive move in nearly all cases, I'd rather support that more directly.

If cases other than "nondestructive move" are common enough, I'd consider something like this syntax instead:

  (task <- nil).cancel()

But I strongly suspect this isn't a common enough pattern to warrant introducing an operator.

> Question: For trivial backwards-compatible API changes like this, does a proposal PR need to be submitted to the swift-evolution repo, or is discussion on this ML sufficient before submitting a patch?

A proposal is needed for all new/changed API.

-Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/bf7b8587/attachment.html>