ensure len and capacity methods reflect their intentions

[neevek]

No description provided.

[link2xt]

The implementation of Realloc trait for Vec should also be replaced to operate on the vector capacity rather than filling the vector with Default values. Also proper documentation comments are needed to describe what these methods do. Then this can be released as a major release.

I opened #5 suitable for a minor bugfix release, but I agree that .capacity() implementation in a Vec trait should not call .len().

[link2xt]

@neevek See discussion at async-email/async-imap#77 (comment), maybe it is not needed to have additional method because poolable vector is supposed to have exactly the same length and capacity all the time. I don't know what is the idea about HashMap though, we definitely cannot pre-fill it with default values as we cannot generate "default keys".

@flub Maybe we drop HashMap support completely, is anyone using it? It is inconsistent with what Vec does, because it reallocates capacity while Poolable::capacity() looks at the length. Maybe we better focus this crate at allocating Vec only or even Vec only.

[link2xt]

This changes semantics quite a bit and breaks len == capacity invariant mentioned in async-email/async-imap#77 (comment)
I think this line should be reverted.

[neevek]

I agree that this completely changes the original semantics, and that indeed will break code that uses the crate.
How about adding another alloc function that only reserves the requested size of memory, and doesn't fill the buffer with default values, which makes len work the way I intended, for example adding a reserve associated function, code that relies on alloc are not affected, and new code can choose to use alloc or reserve.

[neevek]

If that is okay, we can keep the implementation of the Realloc trait unchanged, and add a Reserve trait that provides a reserve function for poolable objects, or maybe we don't even need to do that since only Vec is used as poolable object.

[link2xt]

This was explicitly changed in f4c91d7 with a comment, so I am not sure we should just revert it. There is a PR #1 with more reasoning.

[neevek]

@link2xt I use byte-pool as an alternative to Vec<u8> just for having its poolable feature, so I can simply push data to the buffer and it grows its capacity as needed. Since the buffer object Block is Derefed to a Vec, I think Vec's features should be retained. In my use case, I need to check how much data have been pushed into the buffer, and I also need to slice the buffer, so len and capacity mean different things.