58ce05ff9a
This is a somewhat involved change with two breaking API changes: 1) Lua::coerce_xxx methods now return Option (this is easier and faster than dealing with Result) 2) rlua numeric conversions now allow more loss of precision conversions (e.g. 1.5f32 to 1i32) The logic for the first breaking change is that mostly the coerce methods are probably used internally, and they make sense as low-level fallible casts and are now used as such, and there's no reason to confuse things with a Result with a large error type and force the user to match on the error which will hopefully only be FromLuaConversionError anyway. The logic for the second change is that it matches the behavior of num_traits::cast, and is more consistent in that *some* loss of precision conversions were previously allowed (e.g. f64 to f32). The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have different behavior when given, for example, the number 1.5. I still think this is the best option, though, because the Lua::coerce_xxx methods represent how Lua works internally and the standard C API cast functions that Lua provides, and the ToLua / FromLua code represents the most common form of fallible Rust numeric conversion. I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an error, but it seems inconsistent to allow f64 -> f32 loss of precision but not f64 -> i64 loss of precision. |
||
---|---|---|
.. | ||
compile-fail | ||
compile-fail.rs | ||
function.rs | ||
scope.rs | ||
string.rs | ||
table.rs | ||
tests.rs | ||
thread.rs | ||
types.rs | ||
userdata.rs |