[swift-evolution] Improved value and move semantics

[Haravikk]

> On 29 Jul 2016, at 17:42, Bram Beernink via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi all,
> 
> Would it be possible to improve value and move semantics (performance) in Swift? Consider this possible Swift code in a future release of Swift:
> 
> let array1 : [String] = ["Val1", "Val2"]
> let array2 = array1.appended(“Val3”) // Copy of array1 with “Val3” appended. array1 is left untouched. Nothing special yet.
> var array3 : [String] = [“Var1”]
> array3 = array3.appended(“Var2”) // array3 can just be mutated to add “Var2”, while maintaining value semantics. Swift can recognize that array3’s old state is not referenced anywhere in the future.
> let array4 = array2.appended("Val4").appended("Val5") // Copy of array2 with both "Val4" and "Val5" appended. In this case, “Val5” can also be appended by mutation.

Well, for the array3 = array3.appended("Var2") example this could possibly be addressed by an attribute to indicate to the compiler that .appended() has a mutating variant, as this will allow it to issue a warning when the assignment is to the same variable, which would address that simple case (and provide more awareness of the mutating options and encourage developers to use them).

> This example illustrates improved value semantics with a string array. But it would be good if this can work with any struct. Maybe via something similar to isUniquelyReferenced? Or maybe you can even have a “smart” self in a non-mutating func in a struct:
> struct Array<T> {
>     func appended(e : T) -> Array<T> { // No mutating keyword!
>         self.append(e) // self would either be mutated here if the current ref count of self is 1, and self is either a “rvalue” or self’s old state cannot possibly referenced anymore after this call. Otherwise, "self” would actually be a copy of self.
>         return self
>     }
> }

I don't know about allowing mutation of self in non-mutating methods, that seems confusing; however, I'd be surprised if the compiler doesn't already detect variables that only exist to create a copy that is discarded.

The compiler should already be trying to inline very simple methods like the common copy -> mutate -> return style of non-mutating implementations, in which case it should be able to identify that a copy is being created only to overwrite the original anyway, so can be eliminated. Do you believe that this isn't currently being done?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160730/47bbfc1c/attachment.html>