The following lets us define a table with a type taking integer indices in exchange for string or integer or nil values, with an appropriate table constructor.
local diag_test: {integer: string|integer|nil} = {"HI", 1}
And now if we give an inappropriate table constructor {"HI", 1, {"another table"}}, we get the following diagnostic:
arraydiag.tl:3:7: type error, attempt to assign '{1:string, 2:integer, 3:{1:string}}' to '{integer:(string | integer | nil)}'
Where it refers to the type we specified as {integer: (string|integer|nil)}. This obviously means the same thing, although writing the mapped type as a 1-tuple is actually a syntax error in the language:
The language support this way of writing a table spec, if it is well-defined, since its intention makes sense and could be clearer separating e.g. complicated union types.
Or, the compiler makes the type spec consistent for tables in error output: the difference is pointless and may cause confusion (and seems accidental).
A minor problem and possible source of confusion.
The following lets us define a table with a type taking
integerindices in exchange forstringorintegerornilvalues, with an appropriate table constructor.And now if we give an inappropriate table constructor
{"HI", 1, {"another table"}}, we get the following diagnostic:Where it refers to the type we specified as
{integer: (string|integer|nil)}. This obviously means the same thing, although writing the mapped type as a 1-tuple is actually a syntax error in the language:I propose either: