Closed tpdickso closed 7 years ago
This is a mildly breaking change, as it requires that AnyLuaValue
and AnyHashableLuaValue
be read from an AsMutLua
as opposed to an AsLua
, but this would always have been the case as long as the requirement on AsLua
is not to touch the lua stack. Reading a table requires AsMutLua
since as far as I know there's no way to do it without mutating the lua stack, so requiring only AsLua
was probably incorrect to start with when LuaArray
is a valid variant.
I'm not sure exactly why &mut
fixes it, but thanks!
As for the breaking change aspect, it's not a problem.
My best guess is that it's a sort of a "linked list problem", where you can't have a struct Node { data: u32, next: Node }
, but you can have a struct Node { data: u32, next: Box<Node> }
, and casting lua
to an &mut AsMutLua
is the equivalent of adding that layer of indirection so that the compiler doesn't choke on itself trying to evaluate the recursive type. As to why that's necessary, I have absolutely no idea!
This, as far as I can tell, solves the issue of recursive
&mut
crashing the compiler in the same way that it was solved inPush
.Tests are a bit hairy but I can't think of a cleaner way to write them at the moment.