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?
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.
also, !isimmutable
feels unnecessarily redundant as it holds multiple negations
See also the discussion in #18168.
Agree. In fact we can add ismutable
now and silently deprecate isimmutable
.
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)
isimmutabletype
is not all there yet (https://github.com/JuliaLang/julia/issues/30210).
+1 to introducing ismutable
.
It seems that this issue is closed now. Is it still open?
I am a beginner, looking for a "good first issue"! :)
Yes seems to be fixed in #34518
Most helpful comment
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 ismutable
, switching over the predicate makes sense too. Of course, we can't actually change it until 2.0.