Hi Rick, thanks for replying!
I think limitations are sometimes as important as flexibility.
I witnessed situations where there was no alloted time in the schedule
for refactoring or changing legacy code that had no design, and the
problem built up farther. I think sometimes it's better for the compiler
to enforce: "you just can't do it".
This is one of those specifications. The programmer gets another level
of declaration from this permission/ownership perspective.
A way to specify on the outside (signature) what is going to happen,
generally, inside the function.
Of course, it's a rough idea, it could be improved or consolidated with
another feature you had in mind.
In part 7.4 argument passing style, the following example
fn vec_push(&v: [int],elt:int) {
v += [elt];
}
will be written:
fn vec_push(rwv: [int],roelt:int) {
v += [elt];
}
from the signature itself, you can already deduce that elt would not be
changed inside the function, that the vector will be read and written to.
note that a decision should be made, whether the parts of a record
argument are considered individually or as a whole.
same for a data structure. if a node inside a tree changes, it is
different from the tree being replaced. (in this example, a vector
object and its cells)
this example of a constructor:
fn make_person(+name:str, +address:str) -> person {
ret {name:name,address:address};
}
will be written:
fn make_person(ro +name:str, ro +address:str) -> person {
ret {name:name,address:address};
}
pass by value here is significant, so the new person will not have its
name changed, if the calling side afterwards assigns the str name
reference a different value.
If combined with an iface, the impls will have to conform. I'm not sure
it's a good idea for an interface. maybe too limiting.
I feel that most of the times the distinction of ref/value is about low
level performance.
bye, Kobi
On 4/7/2012 5:01 PM, Rick Richardson wrote:
http://doc.rust-lang.org/doc/tutorial.html#argument-passing
This isn't the most detailed treatise on arguments and ptrs in Rust,
but could you describe a use-case
where ro/rw/out modifiers would be beneficial over what currently exists?
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
