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.
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 typeThis is unsound because we accept any sort of vector for the argument
vec, but the type system only guarantees that we'll write back aconstvector. I thought this was basically harmless, since vectors are uniques, but I forgot that it also implies that we will be covariant with respect toT. 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.