I believe much of the underlying issue is covered by #12808. I have just
filed a pull request #14402 to "fix" the immediate symptoms of this bug
by making it harder to accidentally have struct fields taht conflict
with the private fields of the libstd types.
There's also issue #13126 and RFC #25 about general issues with public
fields/methods and Deref:
Huon
https://github.com/mozilla/rust/issues/12808
https://github.com/mozilla/rust/pull/14402
https://github.com/rust-lang/rfcs/pull/25
https://github.com/mozilla/rust/issues/13126
On 24/05/14 20:52, Paulo Sérgio Almeida wrote:
No, I was just getting feedback if this was a problem already
considered. I have not been following all Rust progress very closely
(trying to catch up now). But I can try to do so later.
Regards,
Paulo
On 23 May 2014 22:06, Kevin Ballard <[email protected]
<mailto:[email protected]>> wrote:
This looks like a legitimate problem. Have you filed an issue on
the GitHub issues page? https://github.com/mozilla/rust/issues/new
-Kevin
On May 23, 2014, at 6:04 AM, Paulo Sérgio Almeida
<[email protected] <mailto:[email protected]>> wrote:
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
<http://arc.rs/>:
pub struct Arc<T> {
priv __x__: *mut ArcInner<T>,
}
Regards,
Paulo
_______________________________________________
Rust-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
