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
The handling of "by mutable reference" parameters is unsound because it doesn't affect variance. This is not news. One place we take advantage of this is vec::push(), which has the type
fn push<T>(&vec: ~[const T], +val: T) { ... }
This is unsound because we accept any sort of vector for the argument vec, but the type system only guarantees that we'll write back a const vector. I thought this was basically harmless, since vectors are uniques, but I forgot that it also implies that we will be covariant with respect to T. When combined with regions, this leads to bugs like #3501. However you can create problems without regions too. Any place where we have subtyping.
Anyway, we had always planned to remove by-mut-ref mode as part of the general "de-moding", but I think we should up the priority for this particular mode. It is not that widely used in any case, though vec::push() is certainly frequent. I am checking out how hard it will be to just purge it altogether.
I am working on this, but ran into a strange bug where apparently, the code after a nested pure fn gets treated as if it should be pure. I'll try to isolate it tomorrow.
Activity
graydon commentedon Sep 17, 2012
Yeah, this is the really major one.
catamorphism commentedon Oct 2, 2012
I'm not sure if we decided this was for 0.4 or not, but I'll try to do it.
catamorphism commentedon Oct 5, 2012
I am working on this, but ran into a strange bug where apparently, the code after a nested
pure fngets treated as if it should be pure. I'll try to isolate it tomorrow.handle field attributes when aligning a struct's fields (rust-lang#3513)
Auto merge of rust-lang#3513 - rust-lang:rustup-2024-04-25, r=RalfJung
Merge rust-lang#3513