On Aug 19, 2012, at 11:49 AM, William Adams wrote: > createstring(buff, len); > > Question: Is there an easier way to conquer this pattern without the error > prone nature of accessing 'needed'? > > Ideally I'd have an 'inout' classifier I could stick onto the parameter. The > FFI is already doing magic to marshal data types, so this would be another > bit of magic. If I had this, then in Lua I could write: > > local len > getvalue(nil, len); > buff = ffi.new("uint8_t[?]", len); > getvalue(buff, len); > ffi.string(buff, len); This is something a PUC-Rio Lua implementation of ffi would not be able to do. Adding inout for ffi alone seems odd. For consistency, straight Lua functions should have this ability too. Saaaay, what happens when you put something which isn't a local lvalue in an inout slot? Multiple return values, as in buff, len = getvalue(nil, len) would not be as nifty, but preserves immutability of parameters, and has well-defined semantics.