Log In  

@zep

It'd be really intuitive and helpful if the select() function also detected a boolean value for the first argument, and returned the first arg if true and the second arg if not.

A lot of us write our own ternary function that does this anyway, because it can work around some gotchas with the cond and tval or fval structure, so this would obviate the need for it while extending the existing API in a very intuitive way.

e.g.

-- this works as you'd expect a C/C++/JS-style "cond? nil : that" ternary op to work
this = select( cond, nil, that )

-- this doesn't, it returns 'that' regardless of 'cond'
this = cond and nil or that

Plus I think this would evaluate faster on the host.

Should probably also treat nil as false, btw, for maximal usefulness and congruence with Lua's concept of conditions.

P#89523 2021-03-25 15:46 ( Edited 2021-03-28 20:34)

1

Two cons:

  • the and-or trick has short-circuit behaviour, but the expressions passed as function arguments are always evaluated
  • this would diverge further from regular lua

The caveat of the and-or trick (unwanted behaviour if the expression after and is falsey) is bad enough that Python for example added a ternary operator, but in Lua only nil and false are falsey, so the problem doesn’t happen with 'and {}' or 'and 0', making it much more acceptable than in Python in my opinion.

P#89532 2021-03-25 16:27 ( Edited 2021-03-25 16:48)

I'm aware the behavior isn't literally a ternary op without the short-circuit behavior. This fact is something that's well-hashed-out on various Lua forums and sites where people have discussed this gap in the language. The same issue exists in all flavors of Lua that I'm aware of.

Having both options available is the best course of action, allowing one to choose whichever suits the situation. Sometimes you need short-circuiting, sometimes you need a mini switch. And sometimes you just need an if/else block.

Also, we're already miles away from standard Lua in the PICO-8 flavor of Lua and the limited mirror of its standard API. Maintaining compatibility isn't really a driving force, in my opinion.

P#89553 2021-03-25 21:11 ( Edited 2021-03-26 01:06)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 07:45:38 | 0.006s | Q:14