>> You are trying to call `mutating` methods on an *immutable* value, the
>> return value of `withCopy`. Normally, the compiler would reject that.
>
> You are right, there would need to be an exception for method cascades. That
> might be a reasonable exception to make because we already know the temporary
> is not just the subject of mutation but also the result of the expression.
> The method cascade just operates on the temporary in-place before being used
> in the surrounding expression or statement .
>
>> Perhaps you could say that method cascades operate on a copy if the receiver
>> is immutable
>
> This isn’t necessary with the previously mentioned exception for allowing
> mutating method cascades on temporaries.
I don't understand what you mean by "temporary". Are you saying that Swift
should distinguish between things which could be mutable but don't happen to be
(variables and subscripts), and things which cannot ever be mutable (functions
and methods)? Will this distinction hold up when we get `inout`-returning
functions?
Basically, what principled rule makes Swift treat this:
immutableVariable..mutatingMethod()
And this:
functionCall()..mutatingMethod()
Differently?
Or is the distinction between this:
immutableVariable..mutatingMethod()
And this:
mutableVariable..mutatingMethod()
And if so, how is that not going to lead to bugs when people move code around?
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
