Rename isimmutable trait to ismutable

[juliohm]

Based on recent discussions on slack, I noticed that the trait isimmutable is an exception to the rule compared to other is* traits in the language. For a concept foo we usually have isfoo as the trait, and !isfoo as the negation. However, with the concept mutable, we currently have is(not)mutable (a.k.a. isimmutable) implemented as the trait.

Would it be possible to deprecate isimmutable in favor of the more readable ismutable trait?

[Keno]

I'm in favor. This naming is left over from when immutables where introduced with the immutable keyword, so it made a lot of sense to use the same terminology. Now that the keyword is mutable, switching over the predicate makes sense too. Of course, we can't actually change it until 2.0.

[rapus95]

also, !isimmutable feels unnecessarily redundant as it holds multiple negations

[stevengj]

See also the discussion in #18168.

[JeffBezanson]

Agree. In fact we can add ismutable now and silently deprecate isimmutable.

[vtjnash]

I think the main reason for the existence of this name might be that they aren't necessarily exact opposites in the type domain (isimmutabletype). In particular, for Abstract and Union, we have that some of the instances might be mutable and others constant. (though also, we have now that AbstractArray.body.body.mutable === false which might be misleading in this example)

[JeffreySarnoff]

isimmutabletype is not all there yet (#30210).
+1 to introducing ismutable.

[ravibitsgoa]

It seems that this issue is closed now. Is it still open?
I am a beginner, looking for a "good first issue"! :)

[KristofferC]

Yes seems to be fixed in #34518