> On 29 Jul 2016, at 17:42, Bram Beernink via swift-evolution
> <[email protected]> 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?_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
