[swift-evolution] [Pitch] Circling back to `with`

[Brent Royal-Gordon]

>> 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