lua-users home
lua-l archive

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


Hi all,

On Oct 23, 2014, at 19:09, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

Not having followed discussions and development of 5.3, but I find it
counterintuitive that %f has to be used in format() where previously %d
and %x would perform the needed conversion of numbers of any type to an
integer. Similarly, luaL_checkinteger() bails out if a numerical value
is not an integer. Is there a rationale to and can someone provide
links to previous discussions of this behavior? Thanks.

My first impression was that both cases needlessly break compatibility,
in both cases the caller is fully aware of the possibility to lose
information, and the convenience of the auxlib function is forfeit. For
me as a caller it would be obvious to distinguish between checking for
a type and to receiving an integer (or representation of such) as the
closest approximation of a number.

Previous versions of Lua never specified *how* numbers were rounded in
the C API. So, if you called something like "string.sub(s,3.6)", you
could receive a string with either 3 or 4 bytes. This does not sound
like a behavior worth keeping.

Yesterday I unpacked lua-5.3.0-rc0 into a project to see how the latest major update would work out.

The most annoying thing I found so far was indeed this "number has no integer representation” issue, most notable with string.format.

This project used string.format("%d”, val) in various places, usually to format a percentage value for UI controls without decimal places. While this obviously just worked before (Lua 5.1) the new behavior is a bit annoying. AFAICS the easiest new way would be to change all of these to "%.0f”, ...

While we can certainly live with this, I wonder if such nitpicking details are really worth to have in a higher level language like Lua. Especially as code like this could work fine at a first glance, and randomly error with values not seen during development & testing.

René

-- 
 ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
 http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de