On 08/07/12 03:35, Niko Matsakis wrote:
Your recent e-mail reminded me that I never responded to this one.
Sorry about that, I was on vacation.
No problem. You deserved a vacation with all the work you are doing on rust.
In general I think the most widely applicable answer is that if you
want to put an enum into a mutable field, just make sure that it is
cheaply copyable. So don't have `option<my_big_record>` but rather
`option<@my_big_record>`. This is probably a good idea anyway, since
you don't want to be copying big things around all the time.
I think that makes sense.
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.
I don't know what's best. We may want to have two functions/methods,
one which expects a pointer and one which doesn't. The copy of an
option<T> is not inherently expensive: its cost will naturally depend
on T. Certainly we want a *option<T> variant for those cases where T
is something prohibitively expensive to copy, such as a unique
pointer, or where it has identity.
We may want both versions for other reasons. In the mode world, it is
common to run up against mode mismatches: the function is declared
with mode ++, for example, but is being used in a context where && is
required. The equivalent in a region world would be a function that
expects T being used in a context where *T is expected. It's also
possible we could write a generic conversion wrapper to deal with this
situation, something like:
fn to_val<T,U>(f: fn(T) -> U, x: *T) -> U { f(*x) }
I can't claim to know what is best either. Hopefully it will become more
obvious over time, especially if/when argument modes are removed (please!).
Thanks
Gareth
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
