Are there other ways of fixing the issue?
>
There is one other way. You can restructure the caller. The most
ambitious would be to change the field from mutable to immutable, but often
that does not work. In that case, you can also update the type of the
record from @{mut f: option<T>} to @{mut f: @option<T>}. You would then
call the function with `*r.f` (where `r` is the record). This is permitted
because, while the `f` field is mutable, the field does not store the
option but rather a pointer to the option. The *option itself* is stored
in immutable memory (that is, the @ box).
> I also have read that argument modes are being removed. How will that
> affect this situation?
>
Probably not at all. What will happen is that the argument will change
from being mode && and type option<T> to type *option<T> (or ^option<T>,
whichever syntax we choose).
> If the single remaining argument mode is by-copy, does that mean this
> issue will go away?
>
The problem goes away if the parameter type is `option<T>`---but I would
guess that in practice the type will be `*option<T>` to avoid the copy.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
