I've been thinking of this setup for a typing solution that could be used for #579 instead of directives for both ambient and implemented code.

/** To mock some exports typescript-to-lua could provide. */
declare module "typescript-to-lua" {
    export interface TupleReturn<T extends any> extends Array<T> { __luaTuple: never }
    /**
     * Specially used to transform provided values into a Lua tuple when used in certain
     * positions.
     *
     * @example
     * const [a, b] = tuple(1, 2, 3);   // --> local a, b = 1, 2, 3
     * return tuple(1, 2, 3);           // --> return 1, 2, 3
     */
    export function tuple<T extends any>(...values: T[]): TupleReturn<T>;
}

For this example the transpiler treats the function tuple differently due to its origin or another distinguishing factor.

Its intended use is outlined in its TSDoc comment.

import { tuple, TupleReturn } from "typescript-to-lua";  // Elide these imports

class Base {
    tupleReturn() {                     // TupleReturn<number>
        return tuple(1, 2, 3);          // return 1, 2, 3
    }
}

class Extension1 extends Base {
    tupleReturn() {                     // number[] ❌ Prevented by TS
        return [1, 2, 3];               // return { 1, 2, 3 }
    }
}

class Extension2 extends Base {
    tupleReturn() {                     // TupleReturn<number>
        const [a, b] = tuple(1, 2, 3);  // local a, b = 1, 2, 3
        const values = tuple(1, 2, 3);  // local values = { 1, 2, 3 }
        const [c, d] = values;          // local c, d = unpack(values)
        return values;                  // unpack(values) -- due to return type
    }
}

// User defined functions that return a tuple of values
declare function unpack<T extends any>(value: T[]): TupleReturn<T>;
declare function tupleReturn(): TupleReturn<number>;

class Extension3 extends Base {
    tupleReturn() {                     // TupleReturn<number>
        return unpack([1, 2, 3])        // return unpack({ 1, 2, 3 })
    }
}

const [a, b, c] = tupleReturn();        // local a, b, c = tupleReturn()

This could be a different way to organize the special behaviour the directives contribute and promote a type-safe solution to ambient and implemented code.

import {
    forRange,   // @forRange alternative
    table,      // @luaTable alternative
    tuple       // @tupleReturn alternative
} from "typescript-to-lua";

for (const i of forRange(0, 10)) {}         // for i = 0, 10 do end

const luaTable = table.from({});            // local luaTable = {}
luaTable.set({}, "table field's value");    // luaTable[{}] = "table field's value"

Could this be worth exploring?

Uh oh!

Explore using custom types instead of tuple and iterator decorators #580

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions