# RFC: "in place" return from imperative function calls Classic List Threaded 26 messages 12
Open this post in threaded view
|

## Re: append to list operator

 чт, 15 авг. 2019 г. в 11:00, Oliver <[hidden email]>: > > On 13.08.19 06:45, Sean Conner wrote: > >   Well, another pain point is > >       veryLongNmae[complexLValue] = veryLongName[complexLValue] + 1 > > a similar and common use case is appending an element to an array: it's also > painful to write: > >         complexLValue[#complexLValue + 1] = newElement; > I can reduce your pain. Just write: table.insert(complexLValue,newElement)
Open this post in threaded view
|

## Re: += operator

 In reply to this post by Oliver Schmidt On Wed, Aug 14, 2019 at 9:32 PM Oliver wrote:I would prefer simple +=. I know from time to time this comes up in this list but I never understood why Lua does not have +=. Problem #1 += could not be added alone. There are a lot of similar operators: -= *= /= %= //= ^= |= &= <<= >>= ..= Should new metamethods be introduced? PRO: they would be useful for DSLs CON: too many metamethods to implement in regular user classes.    Problem #2 I guess XOR is the second popular operator (after addition) used in such short notation. But we can't introduce short notation for XOR "a = a ~ b", because "~=" is already used for non-equality. "^=" in Lua would be raising to the power, not XOR   Problem #3 Why only right addition/multiplication/division/etc? "a *= b" means "a = a * b", but how to write "a = b * a"? This might be important, for example, for matrices.
Open this post in threaded view
|

## Re: RFC: "in place" return from imperative function calls

 In reply to this post by Soni "They/Them" L. On Wed, Aug 14, 2019 at 11:11 PM Soni "They/Them" L. wrote: how about @self (returns the currently executing function object), @var (returns the value of the variable being assigned to) and @table (returns the table being currently constructed)? (@table would be particularly useful for some DSLs. note that all of these only affect the local lexical scope and don't work across modules/function call boundaries.) Oh, yes!  Tables!  I like the idea of referencing the table being constructed:    local vec = {x = get_x(), y = get_y(), len = (@.x^2 + @.y^2)^.5}  Positional references might also be useful:    local a, b = {name = "a", next = @2}, {name = "b", prev = @1}  What about more crazy things?    local function getxy() return x, y end    local len = (@2^2 + @3^2)^.5, getxy() (x = @2 and y = @3 are returned by getxy() but not assigned to variables)   This might be good if it didn't look so Perl-ish :-)
Open this post in threaded view
|

## Re: RFC: "in place" return from imperative function calls

 On 2019-08-17 1:34 p.m., Egor Skriptunoff wrote: > On Wed, Aug 14, 2019 at 11:11 PM Soni "They/Them" L. wrote: > > >     how about @self (returns the currently executing function object), >     @var >     (returns the value of the variable being assigned to) and @table >     (returns the table being currently constructed)? > >     (@table would be particularly useful for some DSLs. note that all of >     these only affect the local lexical scope and don't work across >     modules/function call boundaries.) > > > > Oh, yes!  Tables!  I like the idea of referencing the table being > constructed: >    local vec = {x = get_x(), y = get_y(), len = (@.x^2 + @.y^2)^.5} > > Positional references might also be useful: >    local a, b = {name = "a", next = @2}, {name = "b", prev = @1} > > What about more crazy things? >    local function getxy() return x, y end >    local len = (@2^2 + @3^2)^.5, getxy() > (x = @2 and y = @3 are returned by getxy() but not assigned to variables) > > > This might be good if it didn't look so Perl-ish :-) > here's the thing tho, all the things I listed already exist through the debug library.
Open this post in threaded view
|