Thanks for the response Niko,
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).
This makes sense. However I feel it encourages me to wrap all mutable record/class fields in @ boxes, which to me seems awkward to read/write and probably inefficient too.
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.
Is there potential for the copy to be cheap enough to use `option<T>` (without the pointer)? I feel that by-copy is simpler to reason about and also easier to read/write.
Thank You Gareth
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
