You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not clear to me from #5 if the wrappers are going to continue to live on (IMO they should, the points you made in the first comment are quite good and still apply), but if BString is going to live on, it would be nice if it implemented some of the same constructors as Vec.
Particularly, a Default impl, BString::new, and BString::with_capacity all seem very simple to implement and would improve ergonomics enough to justify their existence. The first one is especially helpful, as without it you cannot derive Default on a type containing a BString.
And ofc feel free to close this if BString is slated for removal soon.
The text was updated successfully, but these errors were encountered:
Yeah I definitely want to keep them around. I purposely kept the API tiny to be conservative, in order to wait for use cases to add more as needed.
The default impl makes sense. However, I was hoping to avoid the constructors in favor of just relying on, e.g., BString::from(Vec::with_capacity(...)). Thoughts?
That's fine by me, had Default been present I probably wouldn't have bothered to file an issue, BString::default() is a little longer than e.g. BString::new() would be, but not exactly hard to type or remember.
All set. I added Default impls for BString, &BStr and &mut BStr and released the changes to crates.io in 0.2.2.
I'm definitely not strongly opposed to adding more constructor APIs to these types, but I'd like to keep them fairly spartan for now until we get more feedback.
It's not clear to me from #5 if the wrappers are going to continue to live on (IMO they should, the points you made in the first comment are quite good and still apply), but if BString is going to live on, it would be nice if it implemented some of the same constructors as Vec.
Particularly, a Default impl, BString::new, and BString::with_capacity all seem very simple to implement and would improve ergonomics enough to justify their existence. The first one is especially helpful, as without it you cannot derive Default on a type containing a BString.
And ofc feel free to close this if BString is slated for removal soon.
The text was updated successfully, but these errors were encountered: