Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add BString convenience constructors (from Vec) #11

Closed
thomcc opened this issue Jul 14, 2019 · 3 comments
Closed

Add BString convenience constructors (from Vec) #11

thomcc opened this issue Jul 14, 2019 · 3 comments

Comments

@thomcc
Copy link
Contributor

thomcc commented Jul 14, 2019

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.

@BurntSushi
Copy link
Owner

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?

@thomcc
Copy link
Contributor Author

thomcc commented Jul 14, 2019

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.

@BurntSushi
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants