RFC: Function default arguments

[Bottersnike]

Rendered

This RFC proposes adding default argument values, removing the need for if arg == nil then arg = default end cases at the start of every function.

TL;DR

function random_point()
    return { x=math.random(), y=math.random() }
end
function print_manhattan_distance(message_prefix = "", point = random_point(), origin = { x=0, y=0 })
    print(message_prefix .. math.abs(point.x - origin.x) + math.abs(point.y - origin.y))
end

along with all of the semantics and type inference you might expect from that example.

I have a working implementation of this feature on my luau fork. The brave adventurer may wish to run a build and play around but otherwise this serves more to show that this could be reasonably add into the language with minimal work required.

[Kampfkarren]

So does this mean function f(x: number = 3) means that I call f() and it compiles as f(3)?

What happens then if I use that function as a first class value?

What happens then in this case?

local function g(callback: (number) -> ())
    callback()
end

g(f)

[Kampfkarren]

I ask because surely something with default parameters cannot have a non-optional argument as part of its type and also be a first class value?

[Bottersnike]

The suggested implementation essentially injects a series of if x == nil then x = default end statements at the start of the function body, so passing f around as a first class value is totally fine. If we run

-- !strict
function f(x: number = 3)
    print(x)
end

local function g(callback: (number) -> ())
    callback()
end

g(f)

we get 3 on stdout as expected.

We do however get a type error of TypeError: Argument count mismatch. Function 'callback' expects 1 argument, but none are specified because the first class value f will have a type of (number?) -> ...any as defined there (to indicate that we need not provide that argument/could provide nil).

Amending g to local function g(callback: (number?) -> ()) that type error goes away.

[Bottersnike]

I've added a section that hopefully formalises that brief explanation into the RFC. lmk if there's still confusion (or another type interaction I've not formalised!).

[stravant]

What is the behavior of the upvalue references in the default value expressions? Do they act like any other upvalue reference from within the body?

For example:

local x = "foo"
local function getX(arg = x)
    return arg
end
print(getX()) --> foo
x = "bar"
print(getX()) --> foo or bar?

[Bottersnike]

It would be bar as the arguments are evaluated every time the function is called. Making this not be the case would require either dropping the behaviour where evaluations are performed at call time, or special-casing single upvalues, both of which I don't think would be ideal?