lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2014-08-01 4:40 GMT+08:00 Sean Conner <>:
> It was thus said that the Great Roberto Ierusalimschy once stated:
>> > I'd like to report back the results: we chickened out and didn't do
>> > it. The end. :)
>> Thanks for the feedback.
>> Just in case, Lua 5.3 will have compile-time options for easily
>> disabling these coercions (one for string->number, another for
>> number->string), but the "standard" will be with coercions enabled.
>   Could you possibly have three levels?
>         1. Status quo
>         2. Warn about coercions as they happen
>         3. Disable coercions.
>   #2 would be very helpful when trying to update the code to avoid
> coercions.  Or, if that can't be done, a call to determine which "optional"
> features are enabled/disabled.
>   -spc

When we are in C modules, how to avoid coercions is better to know,
sometimes we need:
 - read exactly a number/string.
 - read a number/string, do not care about the real type it is.
 - explicit convert a number to/from string.

we can done 3 with lua_strtonum and luaL_tolstring. and currently
lua_tonumber(x)/lua_tointeger(x) does 2.

currently we can only does 1 with lua_type() to get exactly type.

if we do not care about compatible, using lua_tonumber/lua_tointeger
as exactly convertion to done 1, and add luaL_tonumber/luaL_tointeger
(just like luaL_tolstring) maybe better.

maybe we can use this policy: APIs in Lua core don't follow
metamethods, and APIs in lauxlib does.

so we can remove lua_raw* functions from core, and add these functions to luaL_*

but that will break most of codes :(

Xavier Wang.