Implement Container for some Reader/Writers

[SiegeLord]

It seems useful to have the ability to query the length of some Reader/Writers. I implemented it for Reader/Writers for which it made the most sense to me. E.g. I omitted TeeReader as it's not clear what length would refer to in that case.

Notably missing is the implementation of this for File, but I don't know if it can be done in general, as the stat function can fail. Maybe this isn't the right approach at all and a new trait is required (akin to Iterator's size_hint).

My use case, incidentally, is to pass a Rust Reader/Writer to a C library custom file interface which, amongst other things, requires me to report the size of the 'file'.

[huonw]

Is this true? What about something like LimitReader::new(BufReader::new([]), 100), where the reader is actually empty?

[alexcrichton]

I'm a r- on this change. All generic reader/writer wrappers should provide access to their innards for this kind of inspection. Requiring a Container implementation for all wrappers seems like too much of a burden to authors.

I feel like patterns like this encourage implementing all traits for wrappers of types that implement all the same traits, which seems near impossible to do.

[lilyball]

I agree with @alexcrichton.

[SiegeLord]

All generic reader/writer wrappers should provide access to their innards for this kind of inspection.

Wasn't that what Decorator was (#11394)? Do you suggest re-introducing it?

[alexcrichton]

I don't think the Decorator trait should be necessary, it's just one more trait to import that isn't all that necessary. Types should provide some form of accessor via get_ref, get_mut, a public field, etc.

[SiegeLord]

I'm not sure how that helps generic code at all.

If all you're concerned about is the burden on the writers of wrappers, then a Decorator trait would be the solution:

trait Decorator<T>
{
    fn get_ref<'l>(&'l self) -> &'l T;
}

impl<T: Container, D: Decorator<T>> Container for D
{
    fn len(&self) -> uint
    {
        self.get_ref().len()
    }
}

[huonw]

A generic implementation conflicts with all others, so that last impl would mean nothing else can implement Container.

[SiegeLord]

Ah... nevermind then. I'll have to think about a solution for my use case that is more palatable...