Allow "extension" of types from other modules

[jethrogb]

I'll start with some example code:

use std::intrinsics::cttz32;
use std::collections::{Bitv,BitvSet};

pub trait LowestBit
{
    fn lowest_bit(&self) -> Option<usize>;
}

impl LowestBit for Bitv
{
    fn lowest_bit(&self) -> Option<usize>
    {
        for (idx,&word) in self.storage.iter().enumerate()
        {
            if (word==0) { continue }
            return Some(idx*32+(unsafe {cttz32(word) as usize}));
        }
        return None;
    }
}

fn main() {
    let mut v=BitvSet::new();
    v.insert(1242);
    println!("{}",v.get_ref().lowest_bit().unwrap());
}

This currently fails on the privacy of the storage member of Bitv:

tmp.rs:22:22: 22:34 error: field `storage` of struct `collections::bit::Bitv` is private
tmp.rs:22       for (idx,&word) in self.storage.iter().enumerate()

I'm not sure if the code above should "just work", but I do believe there should be a way to say "I know what I'm doing, just give me access to private members," or perhaps something along the line of "protected" members. In the example above, it would be impractical to reimplement Bitv just to add the lowest_bit function.

[sfackler]

The entire point of privacy is to prevent this exact thing.

[alexcrichton]

Yes as @sfackler said this is currently intended behavior. Privacy is used to hide implementation details for reasons such as safety and future refactorability. This function will either need to be implemented in terms of the existing public API or added to the Bitv in the standard library.

[jethrogb]

"This function will either need to be implemented in terms of the existing public API or added to the Bitv in the standard library."

That's besides the point, the code above is just an example of a situation where one might want to add functionality to an existing class. Both of your proposed solutions are unlikely to be practical in many cases. For example, in this case using the public API would be horribly slow. Implementing a function in the standard library locally is not portable.

As I said in my original comment, in C++, you can declare something protected so that people can base their code on yours. In Ruby, you can just add your function to a class or use modules to extend a class. In Rust this is currently not possible, don't you think that this should be considered?

[jethrogb]

I realize the bug tracker is not the appropriate place to discuss this, but the discussion forum wasn't linked from the rust-lang homepage so I didn't know it existed. See http://discuss.rust-lang.org/t/extending-existing-functionality/1289

[alexcrichton]

Yes currently in Rust this is not allowed due to the design of privacy, but it looks like you've figured out the right thing to do, thanks for starting a discussion!