Open zolyfarkas opened 8 years ago
Internally, Chris said:
"It's a binary-incompatible (but source-compatible) change. That said, it looks like Ints.tryParse and Longs.tryParse are both @Beta, so we're allowed to make binary-incompatible changes to them. We might still break people who ignored the @Beta policy, so we'll have to weigh that against the gains. Alternatively, we could add CharSequence overloads. That would make the API look a little bigger and scarier than it is, so I guess every approach has some small pros and cons."
Overloads would work, the only concern is that the extra indirection (assume no copy paste) increases the likelihood of hitting the MaxInlineLevel limit which might result in perf degradation in certain use cases.
Hello,
Regarding #5465, I do not have an example of actual code of mine which uses .tryParse on different implementations of CharSequence other than String. However, there might be some cases an overloading method would be better. For example, cases when manipulations and logic should be applied on a CharSequence is better done on StringBuilder or StringBuffer(Thread-safe).
As for the moment, the algorithms are the same as the .tryParse(String) ones. I personally thinks that the CharSequence version can be used in more cases.
can we make :
Ints.tryParse(String s, int radix) Longs.tryParse(String s, int radix)
more flexible:
Ints.tryParse(CharSequence s, int radix) Longs.tryParse(CharSequence s, int radix)
?