Intent to change: Multiple returns from Computed

[dphfox]

Starting with Fusion v0.2, you may see this warning in your output.

Returning multiple values from Computeds is discouraged, as behaviour will change soon - see discussion #189 on GitHub.

This warning will be triggered whenever your code returns more than one value from a Computed callback:

local computed = Computed(function()
    return "one", "two", "three"
end)

How do you return multiple values?

In Lua, it is possible for functions to return multiple separate values, by providing them as a comma-separated list after the return keyword. The multiple values can then be captured by assigning to multiple variables at the same time:

local function multiReturn()
    return 2, "foo"
end

local thing1, thing2 = multiReturn()
print(thing1) --> 2
print(thing2) --> foo

It's important to note; this is not the same as returning a table of objects. Tables are single values - they just contain multiple other values inside of themselves, in the form of keys and values.

local function tableReturn()
    return { 2, "foo" }
end

local thing1, thing2 = tableReturn()
print(thing1) --> { 2, "foo" }
print(thing2) --> nil

This post does not refer to returning tables of values. It only refers to the first example, where multiple values are being returned outside of a table.

How do Computeds handle multiple returns right now?

Right now, Computeds adopt the first value you return from your callback, and discards all other returned values.

local computed = Computed(function()
    return "one", "two", "three"
end)

print(computed:get()) --> one

What's going to change?

As part of ongoing work to introduce better memory safety into Fusion, Computeds will soon be able to define custom destruction code to clean up previously generated values when they are no longer being used. More information about destructors is provided in this other discussion.

The existing ComputedPairs (v0.1) and ForKeys/ForValues/ForPairs (v0.2) objects already implement destructors. With these changes, we intend to bring the same APIs to Computed.

Those existing objects allow you to pass extra data to the destructor by including it after the returned values:

local values = ForValues(
    {1, 2, 3, 4, 5},
    function(num)
        -- you can return a value, AND a piece of extra data here...
        return num, "extra data"
    end,
    function(num, extraData)
        -- and BOTH will appear as arguments in the destructor.
    end

In the future, we intend to bring this behaviour to Computeds too:

local computed = Computed(
    function(num)
        -- you can return a value, AND a piece of extra data here...
        return num, "extra data"
    end,
    function(num, extraData)
        -- and BOTH will appear as arguments in the destructor.
    end

In addition, Fusion's default cleanup destructor will accept multiple arguments:

local event1 = workspace.Changed:Connect(...)
local event2 = Players.PlayerAdded:Connect(...)

Fusion.cleanup(event1, event2)

print(event1.Connected) --> false
print(event2.Connected) --> false

Why could this cause a problem?

We want to make sure that we don't accidentally obscurely break people's code. It's unlikely - but entirely possible - that some code may depend on Computed implicitly discarding extra returned values. For example:

local target = Value(workspace)
local canGetChildren = Computed(function()
    -- this could return true AND an array of instances!
    return pcall(game.GetChildren, target:get())
end)

As we implement destructors, we will be encouraging developers to annotate their Computeds with Fusion.cleanup when destruction behaviour is needed. However, this will change how extra returned values are handled - the extra values may be destroyed instead of being discarded, which could break some code.

What are we doing about it?

To alert people who may be at risk of unintended behaviour from these potential changes, we will not pass extra values to the destructor for Computeds for the time being. Instead, we will warn you when you return multiple values. This should give you time to find and adjust any problematic code snippets that may be affected as part of these changes in the future.

This should not generally affect most people though - this is mostly a proactive measure against rare issues.

If you have any questions, feel free to reach out!