Type refinements should not apply to lvalues.

[HarmosCreations]

function public:Heal(timer:number)
	
	local self :Healing = self
	
	if (self.Healing == true) then return end
	
	self.Healing = true

--Type 'true' could not be converted into '~true'; type true (true) is not a subtype of ~true.negated() (true) Warning 1
--Type 'true' could not be converted into '~~(false?)'; type true (true) is not a subtype of ~~(false?).negated() (~(false?)) Warning 2
--both warnings comming from self.Healing = true 
-- i also don't know why the warning went from ~true to ~~false just reloaded the script
        

        .....
        self.Healing = false

--if i change the if statement to not self.Healing

        self.Healing = false -- Type 'false' could not be converted into '~(false?)'; type false (false) is not a subtype of ~(false?).negated() (false?)

function new:
local self = setmetatable({}, {__index=module}
self.Healing = false :: boolean

i have met this issue a lot if statements have the power to change the meaning of a variable in some cases it's good but in some other cases it is annoying.

is there a way to go around this or is this a bug?

[hgoldstein]

As a heads up, on GitHub formatting large blocks of code requires at least three backticks instead of just one, so you'll want to write:

I have run into an issue:
```
local function foobar()
    -- Some comment about the code
    return 42
end
```

... instead of:

I have run into an issue:
`
local function foobar()
    -- Some comment about the code
    return 42
end
`

I hope you don't mind I've edited your comment to do so and make it more readable.

I think the issue here is similar to some other issues around dataflow / type state, where narrowing the read type causes us to also narrow the write type.

[HarmosCreations]

As a heads up, on GitHub formatting large blocks of code requires at least three backticks instead of just one, so you'll want to write:

I have run into an issue:

local function foobar() -- Some comment about the code return 42 end

... instead of:

I have run into an issue:
`
local function foobar()
    -- Some comment about the code
    return 42
end
`

I hope you don't mind I've edited your comment to do so and make it more readable.

I think the issue here is similar to some other issues around dataflow / type state, where narrowing the read type causes us to also narrow the write type.

thanks not sure why github just takes the code into comments and back into code very wierd

[OverHash]

A simpler reproduction, if it helps:

--!strict
local MyModule = {}
MyModule._isEnabled = true :: boolean

assert(MyModule._isEnabled, `type solver`)
MyModule._isEnabled = false -- Produces 'TypeError: Type 'false' could not be converted into 'true'', should produce no type error