It would probably be good to remove the lib function altogether.

ok, I think I got it all now.

I did some benchmarks and I'm getting mixed results:

In Lua 5.3 IIFEs are always faster than box/unboxing around 400%.

In LuaJIT IIFEs are faster around 20-50% for small arrays.
12% faster for an array size up to around 5000000.
After that boxing/unboxing is significantly faster (500%).

Tested Code:

-- box/unbox
for i=1, arrSize do
  y = ((arr[i]) and {true} or {false})[1]
end

-- IIFE
for i=1, arrSize do
  z = (function (condtion, val1, val2)
    if condtion then
      return val1
    else
      return val2
    end
  end)(arr[i], true, false)
end

I would argue that 99.9% of the time arrays have less than 50 Million entries, in which case IIFEs are defintly faster. Also I don't think you usually find ternaries that often in tight loops, but that's pure speculation.

So we should still remove the lib call but replace it with IIFEs instead of boxing/unboxing.

Wow thats really interesting. I had no idea IIFEs are that well optimised in lua. We should definitely use IIFEs then.

Did some more testing seems like:

local libTernary  = function (condtion, val1, val2)
  if condtion then
    return val1
  else
    return val2
  end
end

for i=1, arrSize do
  z = libTernary(arr[i], true, false)
end

performs exactly the same as:

for i=1, arrSize do
  z = (function (condtion, val1, val2)
    if condtion then
      return val1
    else
      return val2
    end
  end)(arr[i], true, false)
end

in both JIT and 5.3, so we might aswell keep the lib function since its a bit more readable and adjust it to take the 2 raw expressions as parameter without wrapping them in extra functions.

However, the wrapping is necessary to perform lazy evaluation which otherwise might introduce unwanted side effects. Can you also benchmark the performance with function wrapping?

Okay getting somewhat different results now:

--lua maxntest.lua
arrSize:	5000000

boxUnboxTime time:	2.580266
IIFE time:	0.634437
lib time:	0.630949
wrap time:	0.640842

--luajit maxntest.lua
arrSize:	5000000

boxUnboxTime time:	0.054687
IIFE time:	0.424994
lib time:	0.049987
wrap time:	0.770319

That might be the case because I do all these tests in one file, should probably be executed all separately to make sure they all have the same conditions (stack, heap...).

Here is the code I used: https://gist.github.com/lolleko/8cd4be25b91a8c13c6472863aa6b3868

Feel free to perform your own benchmarking.

I think if we introduce a performance optimising change like this we should make sure it actually performs better.

Completely agree. Here I just assumed that function calls must be slower than table allocation and lookup. I will try some own benchmarking later.

Thanks for reminding me to always benchmark before optimising. So as boxing/unboxing is expensive we should definitely replace it with an IIFE. In the implementation below only one call is necessary as opposed to two when using the library function. So it seems performance using IIFE is better on all non-jit implementations.

Code: https://gist.github.com/TheLartians/0b8bbdc551b67b7205e347df7525c205
Benchmark:

lua5.3 benchmark.lua 
boxUnboxTime time:	1.517611
IIFE time:	0.322223
lib time:	0.420415

lua5.1 benchmark.lua 
boxUnboxTime time:	1.444085
IIFE time:	1.084926
lib time:	1.961076

luajit benchmark.lua 
boxUnboxTime time:	0.041535
IIFE time:	0.254946
lib time:	0.371651

In my benchmark when using liajit, boxing outperforms the other approaches by an order of magnitude, so for luajit we should use the boxing approach.
PS: I adjusted the previous benchmark code so that a variable is captured in the closures and called the resulting function to resolve the conditional statement.

IMO we should have no boxing/unboxing on things guaranteed not to produce side effects, which is the most common case when referring to literals or variables

@DoctorGester the boxing/closures are necessary even without side effects when dealing with boolean or possibly undefined values, when using the and/or syntax. The reason being that statements like c and false or true always returns true, while the boxed statement (c and {false} or {true})[1] works as expected. Alternatively, when there are no side effects we could use a lib call such as libTernary(c, true, false). However, in my benchmarks this is still equal or slower than the more general IIFE approach on lua5.3 or boxing in luajit. Feel free to try it yourself: https://gist.github.com/TheLartians/0b8bbdc551b67b7205e347df7525c205 .
In the long run, we can probably introduce temporary variables and avoid the ternary statement altogether, however this requires AST transformations.

I understand the problem, however most cases could be handled with the usual lua ternary, I don't think settling for a general solution which is in many cases worse than a specific one is a good idea. Since it's typescript we should assume the type is known and understand what's a boolean/nullable type and what isn't. And yeah a temporary variable would be preferable in other cases

One thing to keep in mind is that without strict null checks enabled, any type could be nullable.

You can always go for the most defensive version when type information is unreliable.

I've added a isNonFalsible helper function that currently returns true when the type is a non-boolean literal. In that case the ternary is transpiled without protecting boxes or closures.
Are there more cases we can easily check that are guaranteed to be non-falsible?