On Wed, Apr 17, 2013 at 1:59 PM, Matthieu Monrocq <[email protected]> wrote: > > > > On Wed, Apr 17, 2013 at 9:24 AM, Eddy Cizeron <[email protected]> wrote: >> >> >> 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. > > > I am not sure. > > Whilst the head of the list will be private to the list, there is no reason > that the *node type* be private. Expose the node, built iterators that take > a reference to a node in their constructor, and have the list build the > begin/end iterators (I guess). All iterations can be done safely... > > Of course, it does mean that you have an issue whenever you wish to "erase" > an item by passing its position (unless you use unsafe code to make the > reference mutable again). > > > But that is, I think, a wrong example. Iterators are unsafe. You can easily > keep dangling iterators aside and having them blow up in your hands. > > > On the other, if we shunt external iterators and implement iteration with a > "foreach" method accepting a predicate, then we do not need to expose the > list internals. Give the predicate the ability to "influence" the list it is > running on (returning an enum "Stop/Remove/...") and you are on. > > > I am not saying that there is absolutely no reason it will ever be needed, > but I am challenging the needs exposed so far :) > > -- Matthieu > >> >> >>>>> >>>>> 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 >> > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
You can write safe external iterators by using lifetimes. The compiler will enforce that the list is frozen while you have iterators - completely statically for all owned types, and dynamically for @mut boxes. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
