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.
On Tue, Apr 16, 2013 at 10:11 AM, Matthieu Monrocq < [email protected]> wrote: > I would also had that before jumping straight to direct access, one should > carefully measure. With inlining and constant propagation I would not be > surprised if the optimizer could not turn an access via the public API into > as efficient code as a direct access to the field in the trait method > implementation. > > And if you really need another access method, then maybe it should be > added to the type directly ? > > > On Tue, Apr 16, 2013 at 6:23 PM, Brandon Mintern <[email protected]>wrote: > >> I was about to write how I can understand the use case. That often for >> efficiency (runtime, memory, or concision) reasons, it's helpful to program >> to an API other than the public one. That in the process of implementing an >> interface on some existing type, it often needs to be reworked a bit to >> make it more flexible and extensible. That not having protected might >> result in a lot of unsafe declarations sprinkled around. >> >> 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. 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. >> >> >> On Tue, Apr 16, 2013 at 3:08 AM, Daniel Micay <[email protected]>wrote: >> >>> On Tue, Apr 16, 2013 at 5:53 AM, Eddy Cizeron <[email protected]> >>> wrote: >>> > >>> > Hi everyone >>> > >>> > I was thinking: wouldn't it be useful if rust also had a "protected" >>> > visibility modifier for struct fields with the following meaning: >>> > A protected field in a structure type T is accessible wherever a >>> private one >>> > would be as well as in any implementation of a trait for type T. >>> > >>> > Just an idea. >>> > >>> > -- >>> > Eddy Cizeron >>> >>> What use case do you have in mind for using a protected field instead >>> of a public one? >>> >>> The use case for a private field is separating implementation details >>> from the external API and upholding invariants. Although it's *possible* >>> to safely access them in an external module by using an unsafe block, >>> if you took into account all of the implementation details and >>> invariants of the type. >>> _______________________________________________ >>> 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 >> >> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
