On Dec 30, 2013 3:41 AM, "Miguel Negrão" <miguel.negrao-lists@xxxxxxxxxxxxxxxxx> wrote:
> I don't find that reasoning convicing at all. Some strings can't be
> parsed into integers so the function must have a mechanism for failing,
> it can throw an error or return a value which represents a failure (nil,
> Nothing, Failure("failure string") etc).
That's reasonable, though there's room to disagree. Plus it would break backward compatibility, so I'd say if we do anything like this, SC4 would be the time.
> How do you even distinguish a
> proper match "0".asInteger from a failure "".asInteger ?
Well, I think the C/Java approach would be to validate the string before calling the conversion function.
I guess that's the disagreement: Should asInteger be a dumb conversion method (as it is now), or should it be a smarter interpreter of a string which may or may not spell out a base 10 integer? Your view suggests that the former approach is either insufficient or maybe outright invalid. If that's what you're saying (a guess on my part, could be wrong), then I'd have to disagree to an extent. You can always compose a smarter converter on top of the "dumb" atoi(), giving you the choice of how to validate the input.
I do agree that the Haskell approach seems an improvement.