RE: Is there an easier way to deal with "inout" parameters

  • From: William Adams <william_a_adams@xxxxxxx>
  • To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
  • Date: Mon, 20 Aug 2012 01:04:12 +0000

Yah, I realize that this is not a practical wish.  I could probably be managed 
for FFI cases, but then the language would start to gain some weird semantic 
garbage.  I guess I'll just have to man up and keep toughing it out.  Probably 
a better scanner/converter could spot these, and come up with proper wrappers 
where necessary.  but, realistically, it happens infrequently enough that all 
the cases will need to be hand inspected and tuned anyway.

> 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.                                        

Other related posts: