[erlang-bugs] string:to_float/1 and string:to_integer/1

Bengt Kleberg bengt.kleberg@REDACTED
Tue May 6 06:58:29 CEST 2008


Greetings,

Since it would be backwards incompatible to just change the existing
functions I would like to suggest deprecating them and instead encourage
the use of io_lib:fread/2 (or erlang:list_to_integer/1 and
erlang:list_to_float/1).


bengt

On Tue, 2008-05-06 at 00:00 +0200, Robert Virding wrote:
> The two functions, to_float/1 and to_integer/1, in string are
> seriously broken as they don't raise an error on wrong type of input
> data but return an error value. This is inconsistent with the rest of
> the string module and most other module in the standard libraries. The
> norm is that bad input data is considered an error. I know it is
> documented but that just makes it a documented bug. They should be
> either changed or removed. Or the rest of string changed to be
> consistent.
> 
> I personally think that these functions anyway should not be in
> string, io or io_lib is a better place for them. Should there be a
> string:to_atom which parses its input string and returns the atom
> which may be at the beginning of the string. Sorry for being sarcastic
> they *are* very weird functions.
> 
> I would also debate the error return if there is no integer or float,
> the user should know what they are doing. Also returning an {error,E}
> tuple and not an {ok,I,Rest} tuple is completely inconsistent, both
> should be tagged. As it now you cannot just matched against the
> success case:
> 
> {Int,Rest} = string:to_integer(String)
> 
> but must use a case as both tuples are the same size and only one is
> tagged. This also breaks a common idiom.
> 
> In all these functions cannot be considered as anything other than mis
> formed bugs.
> 
> Robert
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-bugs




More information about the erlang-bugs mailing list