2013/4/16 Brandon Mintern <[email protected]> > I agree with you completely, Matthieu, but that's not the kind of thing I > had in mind. Consider a LinkedList implementation. Its nodes and their > pointers would be private to the LinkedList, but when implementing an > Iterator for that list, you would need to use that private information to > avoid n^2 performance. >
That's a typical case I had in mind. > And then I thought about it a little more and realized that this is >>> precisely something that's unsafe. Most of my protected fields and methods >>> in Java are accompanied by comments like, "Important note: don't frobnicate >>> a foo without also twiddling a bar." >>> >>> I think you're right, Daniel, that having a layer between public API and >>> present implementation is probably not worth the cognitive overhead. >>> >> I understand your point Brandon. But I could say sometime protected information is not so sensitive. When it is immutable for example. So why not declaring it public? Not to pollute the public interface with data unrelated with the common use (Yes I agree the argument is not very strong) > It seems like it would be Rust best practice when implementing an >>> interface to use the public API of the type to the extent possible, and >>> when necessary for efficiency or other reasons, to use unsafe and fiddle >>> with the private API. >>> >> It could be. But if I'm allowed to play the Devil's advocate this implies that any implentation detail must be thought as potentially accessible (and then as necessarily understandable / documented) from outside (what you call "private API"). This is not the typical approach when considering private data.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
