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.

[Wunder-Wulfe]

I personally do not like the structure of this syntax. I would prefer something along the lines C# with their Null-conditional Operators for some of the use cases listed.

Roblox Type Explanations

This section is for Luau users unfamiliar with Roblox functions and conventions:

hit, object, and part are conventional names for objects under the parent type Instance.

index<Instance, "Parent"> -> Instance?, as the Parent property is nullable.

parentInstance:FindFirstChildOfClass(className) returns Instance? as the object may not be found as a child of parentInstance.

Humanoid is a sub-class of Instance.

index<Instance, "Name"> -> string.

local human: Humanoid? = hit.Parent?:FindFirstChildOfClass("Humanoid");
--[[
eq:

local human: Humanoid? = nil;
do 
    local temp = hit.Parent;
    if temp ~= nil then human = temp:FindFirstChildOfClass("Humanoid"); end
end
]]

-- ...

local name: string? = object:FindFirstChildOfClass("ObjectValue")?.Name;
--[[
eq:

local name: string? = nil;
do 
    local temp = object:FindFirstChildOfClass("ObjectValue");
    if temp ~= nil then name = temp.Name; end
end
]]


-- ...

local getFirst = list[key]?[1];
--[[
eq:

local getFirst = nil;
do 
    local temp = list[key];
    if temp ~= nil then getFirst = temp[1]; end
end
]]

In the above cases, types that are null-conditional, i.e. T? will result in index<T, U>? when evaluated, and types with T would result in regular index<T, U>. This makes sense for the following example:

-- sealed table '{a:{b:string}}'
local t = {a = {b = "some text"}};

local text = t.a?.b; -- text: string
-- 't.a' is '{b:string}' and not 'nil' / nullable, so regular 'a.b' indexing is used: 'index<a, 'b'>'

local grandParent = part.Parent?.Parent; -- grandParent: Instance?
-- 'part.Parent' is 'Instance?' and not 'Instance', so null-conditional indexing is used, resulting in 'index<Instance, "Parent">?' or 'Instance??' aka 'Instance?'
-- in this case, 'part.Parent.Parent' by contrast will emit a 'Type Error' since 'index<Instance?, "Parent">' is invalid

Or, the following syntax for short circuit evaluations, inspired by Initializers in if statements:

local value = if local temp = somefunction() in temp ~= nil then temp else default();
-- or alternatively
local value = if local temp = somefunction() in temp == nil then default() else temp;

In both cases, somefunction() executes once only and default() one or no times, and would create a temp variable scoped to the if statement.

[surfbryce]

@Wunder-Wulfe Would probably be better that you make a RFC for this, probably paired with null assertion operators as well

[alexmccord]

We already had the safe navigation operator RFC and we had to veto it out.

1. RFC: Do not implement safe navigation operator luau#501
2. RFC: Safe navigation operator luau#142

[deviaze]

Not sure if it's ever been specifically considered, but we could adapt Rust's let else syntax, where the else branch must diverge. Maybe we don't have to make our else branches diverge like rust's if they evaluate to the same type (at typetime)? At runtime, if the expression isn't a return it just functions normally as a default value. In Luau it could be like:

local cat = animals_folder:FindFirstChild("Cat") else return nil
print(cat.Position) -- indexing .Position doesn't error because cat can't be nil

-- runtime equivalent to
local cat = animals_folder:FindFirstChild("Cat")
if cat == nil then
    return nil
end

-- as default value

local cat = animals_folder:FindFirstChild("Cat") else default_cat

-- equivalent to
local cat = animals_folder:FindFirstChild("Cat")
if cat == nil then
    cat = default_cat
end

[gaymeowing]

Not sure if it's ever been specifically considered, but we could adapt Rust's let else syntax, where the else branch must diverge. Maybe we don't have to make our else branches diverge like rust's if they evaluate to the same type (at typetime)? At runtime, if the expression isn't a return it just functions normally as a default value. In Luau it could be like:

local cat = animals_folder:FindFirstChild("Cat") else return nil
print(cat.Position) -- indexing .Position doesn't error because cat can't be nil

-- runtime equivalent to
local cat = animals_folder:FindFirstChild("Cat")
if cat == nil then
    return nil
end

-- as default value

local cat = animals_folder:FindFirstChild("Cat") else default_cat

-- equivalent to
local cat = animals_folder:FindFirstChild("Cat")
if cat == nil then
    cat = default_cat
end

You've just described or

[deviaze]

You've just described or

iirc or doesn't work there w/ multirets and also evals if the LHS is false (not just nil)