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

Consider providing "string" to int conversion #336

Open
carllerche opened this issue Dec 3, 2019 · 7 comments
Open

Consider providing "string" to int conversion #336

carllerche opened this issue Dec 3, 2019 · 7 comments

Comments

@carllerche
Copy link
Member

carllerche commented Dec 3, 2019

Basically: https://linux.die.net/man/3/atoi

std already provides such a conversion from &str but not directly from &[u8]

@rizsotto
Copy link

Looks like this crate implemented this functionality. Shall this crate just re-export?

@carllerche
Copy link
Member Author

The goal of bytes is to provide the utilities itself and only depend on other crates in rare cases. Looking at atoi, it also seems to have heavy reliance on traits, which is not a direction we want to go.

@rizsotto
Copy link

Thanks @carllerche for your response. I see what you are saying... On the other hand, serde-json is already depends on atoi crate. So for a user to write a microservice, these dependencies will be pulled in anyway. And killing the traits in atoi could be a nice improvement on that crate. Could you make a ticket on atoi with your suggestion to improve it?

@Ralith
Copy link

Ralith commented Jan 26, 2020

On the other hand, serde-json is already depends on atoi crate. So for a user to write a microservice, these dependencies will be pulled in anyway.

Note that not all users of this crate are writing web services.

@rizsotto
Copy link

On the other hand, serde-json is already depends on atoi crate. So for a user to write a microservice, these dependencies will be pulled in anyway.

Note that not all users of this crate are writing web services.

Yeah, that's true. The point I was trying to make is to reduce the effort to implement the same functionality. And it looks like that atoi is trusted by the serde-json authors. So, why not further improve that crate with this use case too? That would reduce the bloat (duplicate code) for web service authors.

But I don't want to push anything on anybody. Just thought to create a ticket on atoi crate could be good... I find it hard to get those insights that users of my code have. (What are the pain points? Can it be more simple? etc...)

@carllerche
Copy link
Member Author

I don't see atoi in the list of serde-json dependencies?

@carllerche
Copy link
Member Author

I also don't think there is anything "wrong" with how atoi is designed, it just isn't the direction for bytes. It is similar to how byteorder uses traits and bytes does not. There are different use cases / constraints.

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

No branches or pull requests

3 participants