If /// was for the parent and the only way to document things, that would make
it rather problematic to document struct fields and statics.
-Kevin
On Aug 26, 2013, at 2:11 PM, Armin Ronacher <armin.ronac...@active-4.com> wrote:
> Hi,
>
> On 26/08/2013 15:07, Niko Matsakis wrote:
>> I find I have surprisingly strong opinions about this. In particular,
>> I don't care for any of the options. Rather I prefer option D, which
>> looks like:
> To be honest, I think moving docs into the function body is the strongest
> point of Python's docstrings. Primarily because they implicitly nest away
> with the function and if you quickly search for a function (def funcname) you
> don't skip past the docs.
>
> I kinda wish "/// " was for the parent object and the only way to document
> things, but I can see how people don't like that. That would also make it
> work automatically the same for modules and functions and no confusion about
> different documentation comments would arise.
>
> Generally though, I think it would look very clean:
>
>
> pub struct HashMap<K,V> {
> /// A hash map implementation which uses linear probing along
> /// with the SipHash hash function for internal state. This means
> /// that the order of all hash maps is randomized by keying each
> /// hash map randomly on creation.
> priv k0: u64,
> priv k1: u64,
> priv resize_at: uint,
> priv size: uint,
> priv buckets: ~[Option<Bucket<K, V>>],
> }
>
> impl<K:Hash + Eq,V> HashMap<K, V> {
>
> #[inline]
> fn expand(&mut self) {
> /// Expand the capacity of the array to the next power of two
> /// and re-insert each of the existing buckets.
> let new_capacity = self.buckets.len() * 2;
> self.resize(new_capacity);
> }
> }
>
>
> Regards,
> Armin
>
> _______________________________________________
> 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
