Live data from Hacker News

LuaJIT 3.0 proposed syntax extensions

github.com

11–20 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#11

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

Lua basically already has ternary operators anyway since "and" and "or" short circuit. I also don't see the need of adding additional syntax for it.

  local x = condition ? value_a : value b
  local x = condition and value_a or value_b

Re: LuaJIT 3.0 proposed syntax extensions

#13
post #11

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

Lua basically already has ternary operators anyway since "and" and "or" short circuit. I also don't see the need of adding additional syntax for it. local x = condition ? value_a : value b local x = condition and value_a or value_b

> The classic Lua idiom a and b or c has a pitfall when b is nil or false: then c is returned, even when a is truthy.

> E.g. true and false or 42 returns 42, whereas true ? false : 42 returns the (expected) false.

Re: LuaJIT 3.0 proposed syntax extensions

#14

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

I guess for the JS case it makes sense to be able to shave a few characters for file shrinking purposes, but generally I'm more biased to code clarity and "self-explainability"

Re: LuaJIT 3.0 proposed syntax extensions

#15

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

That’s why “if” should just be an expression

Re: LuaJIT 3.0 proposed syntax extensions

#17

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

I find it most useful in languages that have non-mutable variables and you want to avoid a mutable variable or an extra function when the value comes from a simple condition.

Re: LuaJIT 3.0 proposed syntax extensions

#18

Never will I understand ternary operators. As soon as you introduce it, some chuckle heads want to use them everywhere. Worse if the syntax allows nested ternarys. I guess it keeps the language open for code golfing, but it otherwise seems like redundant syntax that at best saves a few characters.

That’s why “if” should just be an expression

This is the best answer in my opinion. Ternary is just sugar for an expressive if. LuaJIT seems to be focusing on adding new syntax though, maintainer might not be amenable to updating existing semantics.

Re: LuaJIT 3.0 proposed syntax extensions

#19
A comment https://github.com/LuaJIT/LuaJIT/issues/1475#issuecomment-47...> has already been made on the issue regarding the ternary operator, recommending `if x then y else z` over `x ? y : z`. This is exactly how it's done with if-then-else expressions in Luau https://luau.org/syntax/#if-then-else-expressions>, another language compatible with Lua, and makes it a ton easier to nest (especially with elseif) and I believe still easier to read than `y if x else z`.
Post reply on HN