As a Roblox developer, it is currently impossible to change a function’s return type based on an argument value.
local function getProductInfo(infoType: Enum.InfoType): (ProductInfo | AssetInfo | GamePassInfo)
-- return product info
end
This function currently returns either a ProductInfo, AssetInfo, or GamePassInfo, but the type checker doesn’t really know which one it actually is, even though it will always be directly determined by the InfoType passed to the function. Ideally it should be possible to define the relationship between argument values, especially EnumItems, and return types.
If Roblox is able to address this issue, it would improve my development experience because I would be able to have more precise type checking.
local function State<T>(key: string, value: T): State<T>
return {
Key = key,
Value = value
}
end
local Activated = State("Activated", false) -- State<boolean>
local TimesClicked = State("TimesClicked", 0) -- State<number>
OP wants a mechanism like function overloading, Luau cant natively support this as a runtime feature due to how functions work, but I still believe it can work as a typechecking feature since the typechecker is declarative.
Here’s an example of function overloading in C# for example:
namespace OverloadedFunction {
internal uint Add(uint a, uint b) {
return a + b;
}
internal uint Add(uint a) {
return a++; // idk if this is valid in cs
}
}
Is there a reason these are not separate functions instead? Huge branches are usually pretty scary and are indicative of a function doing too much.
Regardless, if enum item constants were added (I’m not on that team, but it’s something that ought to exist), you’d be able to hack something together with type functions, with a signature that looks something like:
local function getProductInfo<I>(infoType: I): ProductInfoOf<I>
Or, even without enum item constants, you could use string constants here instead, which would work out of the box.
What I wrote is basically a wrapper for MarketplaceService:GetProductInfo(). I could technically split it into five identical functions with different signatures, but that turns out pretty bloated and also breaks the old “don’t repeat yourself” adage.
Since the parameter’s type would be dependent on the value of its arguments, this would require Dependent-Typing. That is way out of scope, if not infeasible for the Luau typechecker.
Now this could be a different story if there was some type-universe distinction between different EnumItems, but otherwise there is no way to distinguish them apart.