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 <bran...@mintern.net>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 <danielmi...@gmail.com>wrote: > >> On Tue, Apr 16, 2013 at 5:53 AM, Eddy Cizeron <eddycize...@gmail.com> >> 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 >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
