Hi all, (resending from different email address; there seems to be a
problem with my other address)
I don't know if this has been discussed, but I noticed an unpleasant
interaction between private fields in the implementation of things like
pointer types and auto-dereferencing.
The example I noticed is: if I want to store a struct with field "x" inside
an Arc, and then auto-dereference it I get the error:
error: field `x` of struct `sync::arc::Arc` is private
A program showing this, if comments are removed, where the ugly form (*p).x
must be used to solve it:
---
extern crate sync;
use sync::Arc;
struct Point { x: int, y: int }
fn main() {
let p = Arc::new(Point { x: 4, y: 8 });
let p1 = p.clone();
spawn(proc(){
println!("task v1: {}", p1.y);
//println!("task v1: {}", p1.x);
println!("task v1: {}", (*p1).x);
});
println!("v: {}", p.y);
//println!("v: {}", p.x);
println!("v: {}", (*p).x);
}
--
The annoying thing is that a user of the pointer-type should not have to
know or worry about what private fields the pointer implementation
contains.
A better user experience would be if, if in a context where there is no
corresponding public field and auto-deref is available, auto-deref is
attempted, ignoring private-fields of the pointer type.
If this is too much of a hack or with complex or unforeseen consequences, a
practical almost-solution without changing the compiler would be renaming
private fields in pointer implementations, like Arc, so as to minimize the
collision probability, e.g., use something like __x__ in arc.rs:
pub struct Arc<T> {
priv __x__: *mut ArcInner<T>,
}
Regards,
Paulo
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
