{"action":"created","issue":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/1098","labels_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1098/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1098/comments","events_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1098/events","html_url":"https://github.com/rust-lang/rfcs/issues/1098","id":71794043,"number":1098,"title":"Parsing string to integer accepting '0x' + hexadecimal","user":{"login":"comex","id":47517,"avatar_url":"https://avatars.githubusercontent.com/u/47517?v=3","gravatar_id":"","url":"https://api.github.com/users/comex","html_url":"https://github.com/comex","followers_url":"https://api.github.com/users/comex/followers","following_url":"https://api.github.com/users/comex/following{/other_user}","gists_url":"https://api.github.com/users/comex/gists{/gist_id}","starred_url":"https://api.github.com/users/comex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/comex/subscriptions","organizations_url":"https://api.github.com/users/comex/orgs","repos_url":"https://api.github.com/users/comex/repos","events_url":"https://api.github.com/users/comex/events{/privacy}","received_events_url":"https://api.github.com/users/comex/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-04-29T06:44:44Z","updated_at":"2015-04-30T23:25:17Z","closed_at":null,"body":"In many cases, it is useful for a program that parses integers (e.g. from the command line) to accept both decimal and hexadecimal constants, by letting the user prefix the latter with `0x`.  Currently, `FromStr::from_str` (also the destination of `str::parse`) only accepts base 10; `from_str_radix` allows an arbitrary base to be specified, but doesn't have any special magic to parse prefixes.\r\n\r\nIf I were writing `from_str` from scratch, I would suggest having it accept `0x`, perhaps along with `0o` and `0b` like Rust source, because even if many applications don't have any particular reason to expect hexadecimal, there's very little advantage to rejecting it*.  At this point, I guess that would be something of a breaking change, so a new method would be needed; still, I claim such a method belongs in the standard library for the same reason.  Alternatively, `from_str_radix` could accept radix 0 like some other languages' equivalents, although this seems like a hack.\r\n\r\nOther languages' behavior:\r\n- C `atoi` only accepts base 10.\r\n- The C `strtol` family has a mandatory base parameter; base=0 is decimal by default but allows `0x` and `0755` (octal); base=16 accepts `0x`\r\n- Python `int()` is base 10 only by default, but has a base parameter; same behavior as C except `0b` and `0o` are also accepted\r\n- Ruby: `'0x123'.to_i` is 0, but `Integer('0x123')` is 291.  I have no idea.  The latter seems to accept the same as Python.\r\n- JavaScript: `parseInt` by default accepts `0x` and, in some browsers, `0`-for-octal, which ES5 says not to.\r\n\r\n(I certainly don't propose interpreting leading zeroes as octal.)\r\n\r\n* One possible reason to reject alternate forms would be to give each integer a unique input representation, but of course `-0` and `0`, and `008` and `8` parse to the same value."},"comment":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/comments/97998599","html_url":"https://github.com/rust-lang/rfcs/issues/1098#issuecomment-97998599","issue_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1098","id":97998599,"user":{"login":"kballard","id":714,"avatar_url":"https://avatars.githubusercontent.com/u/714?v=3","gravatar_id":"","url":"https://api.github.com/users/kballard","html_url":"https://github.com/kballard","followers_url":"https://api.github.com/users/kballard/followers","following_url":"https://api.github.com/users/kballard/following{/other_user}","gists_url":"https://api.github.com/users/kballard/gists{/gist_id}","starred_url":"https://api.github.com/users/kballard/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kballard/subscriptions","organizations_url":"https://api.github.com/users/kballard/orgs","repos_url":"https://api.github.com/users/kballard/repos","events_url":"https://api.github.com/users/kballard/events{/privacy}","received_events_url":"https://api.github.com/users/kballard/received_events","type":"User","site_admin":false},"created_at":"2015-04-30T23:25:16Z","updated_at":"2015-04-30T23:25:16Z","body":"Hah, nice example. That's a really good point. I'm now in full agreement that it should be opt-in behavior.\r\n\r\nThe simplest change here would be to follow C's lead and allow a `0` value given to `from_str_radix()` to mean autodetect, but I agree with @comex that it's kind of an ugly hack. We could make the `radix` an optional value, but that makes the common case (of providing a radix value) more awkward, and it's not clear if this actually has any benefit over just using `0`.\r\n\r\nI am still a bit partial to my \"alternative\" idea from before, of having a `from_str_config()` method. This would allow us to provide a way to control not only integral prefix parsing, but whether a leading `0` should be treated as octal or whether that should require `0o`, and similarly whether we should accept a binary prefix of `0b`. But I am a bit worried that this is straying to far towards behavior that should be done with a \"real\" parser."}}