RFC: or return syntax

[ctrlaltmilk]

A small syntax extension to make handling nil values easier and more concise.

Rendered

[dphfox]

I would really desperately want to see this - my code is littered with places this would be incredible - but a similar idea I mentioned a while back about "return in expressions" got shot down.

I really hope there is an expression of this design that can be agreed upon.

[alexmccord]

Inconsistent with usual truthiness test. What if the expression evaluates to false?

[ctrlaltmilk]

Probably should have clarified here - the main use case is for expressions that can return nil, but the already-established truthiness rules would be respected.

[bradsharp]

Would or break also make sense? I wonder if we could just allow return and break in expressions where they would otherwise make sense.

[alexmccord]

This is just if local which is proposed in a different RFC, so this isn't a strong motivator.

[ctrlaltmilk]

if local does also solve this problem, but it also creates a new indentation level which is counter to the goals of this RFC.

[alexmccord]

Doesn't compose with multrets.

[ctrlaltmilk]

Why not? As far as I can tell, the only possible reason it wouldn't is if commas were used somewhere else in the expression, which is solved by using a pair of parentheses.

[alexmccord]

or break could work but or continue won't work, which is an unfortunate problem that argues against this design.

[alexmccord]

Parser can't rewrite the AST beyond its local context, so AST changes are required for this feature to work.

[ctrlaltmilk]

That's understandable. Is there some form of AST expansion/lowering pass that this could fit into, or would this need to be supported in the compiler as well?

[ctrlaltmilk]

Would or break also make sense? I wonder if we could just allow return and break in expressions where they would otherwise make sense.

I did consider allowing return and break as expressions, but decided that would lead to confusing edge cases when called from a context where those statements wouldn't apply.

[dphfox]

Here's an idea, or else.

local humanoid = partParent:FindFirstChild("Humanoid") or else return

It's never valid Luau to have the or keyword before an else keyword, so that sequence should be easy enough to detect. That would then allow proper support for or else continue.

And hey, it reads like posh English, that's fun too :)

[gaymeowing]

Here's an idea, or else.

local humanoid = partParent:FindFirstChild("Humanoid") or else return

It's never valid Luau to have the or keyword before an else keyword, so that sequence should be easy enough to detect. That would then allow proper support for or else continue.

And hey, it reads like posh English, that's fun too :)

Feel like it should be orelse to be consistent with elseif, sure its another operator (I think operator is the correct term?) but I don't think anyones naming variables orelse

[gaymeowing]

Also this would have to be

or return ... end

because otherwise this would return the result of PivotTo, as we can't have implicit whitespace

or return
model:PivotTo(CFrame.Identity)

[ccuser44]

This doesn't make to have in Luau and is syntactical bloat. And frankly, just looks kinda ugly.