local connection: RBXScriptConnection | nil
local connection2: RBXScriptConnection | nil
local function updateParams(distance: number, exponentialSpeed: number, speed: number)
distance = (primaryPart.Position - inst.Position).Magnitude
exponentialSpeed = math.floor(self.settings.MaxDistance / distance) / 10
speed = self.settings.SpeedModifier * exponentialSpeed
end
inst:GetPropertyChangedSignal("Position"):Connect(function()
task.spawn(updateParams, distance, exponentialSpeed, speed)
end)
primaryPart:GetPropertyChangedSignal("Position"):Connect(function()
task.spawn(updateParams, distance, exponentialSpeed, speed)
end)
connection = RunService.Stepped:Connect(function() --Save some lag
inst.Position = inst.Position:Lerp(primaryPart.Position, speed)
if typeof(connection) == "RBXScriptConnection" then connection:Disconnect() end --Here it throws an error
end)
connection2 = inst.Destroying:Connect(function()
if typeof(connection) == "RBXScriptConnection" then connection:Disconnect() end
if typeof(connection2) == "RBXScriptConnection" then connection2:Disconnect() end
connection = nil
connection2 = nil
end)
It throws a type error for no reason and I can’t figure why.
Error message: “Type function instance union<blocked-274313, nil> is uninhabited This is likely to be a bug, please report it at GitHub · Where software is built”
I can’t report it just yet on the Github page, but I will try to upload the issue on it as soon as possible.
--!strict
local module = {}
local configurations = {
health = 10;
range = 10;
team = "red";
}
type towerType = keyof<typeof(configurations)>
type health = index<towerType, "health">
function test(param: index<towerType, "health">)
end
return module
You are doing something wrong, and the error is correct, yeah. keyof<typeof(configurations)> gives you the types of all the keys of configurations, i.e. "health" | "range" | "team". Each of these is a string literal type (or string singleton type) corresponding to those keys. The index type function computes the result type of indexing its first argument by a value of its second argument type. That is, your index<towerType, "health"> is asking for “what do I get if I index any of the three strings "health" | "range" | "team" by "health"?” The answer is that it would fail since strings cannot be indexed generally (the exception being that you can access the string library through each string’s metatable, but that metatable doesn’t have a property named health either), and so index is rightfully telling you about the error.
Assuming that you wanted to annotate it to take the type of the value in configurations that corresponds to the key health, that looks a little bit different, e.g.
--!strict
local module = {}
-- adding a type alias here to be very explicit about things
type Configuration = { health: number, range: number, team: string }
local configurations: Configuration = {
health = 10;
range = 10;
team = "red";
}
type towerType = keyof<Configuration>
function test(param: index<Configuration, "health">)
end
-- but this should also work, including if you didn't annotate `configurations`
function test2(param: index<typeof(configurations), "health">)
end
return module
--!strict
local Class = {}
local Mt = {} :: Object
Mt.__index = Mt
export type Object = typeof(setmetatable({} :: {
Property : number,
Method : (Object) -> (),
__index : typeof(Mt),
}, Mt))
function Class.new() : Object
local self = setmetatable({}, Mt) :: Object
self -- new and old : self type is Object
return self
end
-- the new typesolver annotates self as unknown here while the old typesolver annotate it as Object
function Mt:Method()
self -- Old : self type is Object | New : self type is unknown
end
return Class
in the old type solver the type of self in the Method is Object while in the new type solver it is unknown
both screenshots are taken inside of the Method method
old:
new:
I may have defined the type incorrectly, but I donot really know
This is a known issue right now, you can mitigate it yourself by explicitly annotating self in the definition, i.e.
function Mt.Method(self: Object)
-- body of the function
end
If you do this, you can still invoke it later with object:Method() just fine.
We know this is not ideal for folks, and plan to implement shared self type inference at some point in the foreseeable future to rectify this and a myriad of other issues with type inference for object-oriented code.
