fix: MultiReturn unpacking with get accessors is broken · Issue #1542 · TypeScriptToLua/TypeScriptToLua · GitHub
Skip to content

fix: MultiReturn unpacking with get accessors is broken #1542

Open

Description

@Z3rio

Introduction / Explenation

Upon running the example below, you'll quickly realize that the getter function errors, whereas the normal function does not.
Even though they consist of the same code.

The issue seems to be with unwrapping return values in class getters.

What should happen instead?

I think most of us would simply expect both these code snippets to work the exact same, aka to unwrap the return values without any issues.

Reproduction

Code

class TestClass {
  public get Test1(): LuaMultiReturn<[number, number]>{
    return $multi(0, 0);
  }

  public Test2(): LuaMultiReturn<[number, number]>{
    return $multi(0, 0);
  }

  public showcaseIssue(): void {
    const [a, b] = this.Test2();
    console.log(a,b)
    const [c, d] = this.Test1;
    console.log(c,d)
  }
}

const a = new TestClass();
a.showcaseIssue()

Playground Link

Click here

Activity

  1. changed the title [-]fix: retval unpacking in class getters are broken[/-] [+]fix: MultiReturn unpacking with get accessors are broken[/+] on Mar 1, 2024
  2. changed the title [-]fix: MultiReturn unpacking with get accessors are broken[/-] [+]fix: MultiReturn unpacking with get accessors is broken[/+] on Mar 1, 2024
  3. Gudine commented on Oct 24, 2024

    @Gudine
    Contributor

    I'm pretty sure the syntax local c, d = table.unpack(self.Test1) can't work at all in Lua, since multiple returns can only come out of functions, and self.Test1 is a parameter, so it can only give you one value.

    Here's how it'd work in pure Lua:

    t = setmetatable({}, { __index = function() return 1,2,3 end }) -- Makes it so any property of t returns $multi(1,2,3)
    
    a, b, c = t.dummy
    print(a) -- 1
    print(b) -- nil
    print(c) -- nil
    
    print(t.dummy) -- 1
    print(unpack(t.dummy)) -- Error: bad argument #1 to 'unpack' (table expected, got number)

    The only solution would be to make getters actually call the function, but I think that would remove any benefit of using a getter in the first place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions