You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to implement the solution for Dan's Bug based on immutability that I proposed earlier. I have updated the page to describe my latest version, which does not include the separate class of "assignable types". Instead, we make use of #1273 (explicitly mutable local variables) and the work on regions to ensure that the type system can always distinguish immutable and mutable state.
The main change is to prohibit dangerous patterns (as described in the proposal) from being matched against potentially mutable state. An additional change would be to introduce copy patterns, which cause the value being matched to be copied out into a temporary, immutable space (this is more of a convenience than a requirement).
Even if we scale back regions, I think that this approach is simpler and less error-prone than the existing one. It does however require distinguishing "const" references from "immutable" references (right now, both are &&). With region pointers, this is done for us, as we have &T, &const T, and &mut T.
The text was updated successfully, but these errors were encountered:
Seems sane. If it is sound, it'll be a huge improvement over the current checker (less rules to explain, less complexity to allow for accidental holes).
Work is still ongoing. I got distracted by regions, but the two parts are starting to come together, so I'm dusting off my old branch. I may try to land this in the next couple of days (presuming that there are no objections from @brson@catamorphism or @pcwalton), assuming that I can get everything building. One rule that will be enforced is that a local variable passed by a const reference mode (&&) is made immutable for the duration of the call---this rule will be obsolete of course with regions, though a similar rule might apply to borrowing mutable uniques (that is, a ~mut T could be borrowed as a &T---here the mutability was lost, but we can statically guarantee that the ~mut will not be mutated for the time in which the &T is live, so it's ok)
I would like to implement the solution for Dan's Bug based on immutability that I proposed earlier. I have updated the page to describe my latest version, which does not include the separate class of "assignable types". Instead, we make use of #1273 (explicitly mutable local variables) and the work on regions to ensure that the type system can always distinguish immutable and mutable state.
The main change is to prohibit dangerous patterns (as described in the proposal) from being matched against potentially mutable state. An additional change would be to introduce
copy
patterns, which cause the value being matched to be copied out into a temporary, immutable space (this is more of a convenience than a requirement).Even if we scale back regions, I think that this approach is simpler and less error-prone than the existing one. It does however require distinguishing "const" references from "immutable" references (right now, both are
&&
). With region pointers, this is done for us, as we have&T
,&const T
, and&mut T
.The text was updated successfully, but these errors were encountered: