You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using Charm state management library on Roblox Studio, I enabled the long awaited new Beta solver feature.
Although, it now requires me to explicitly cast the argument inside callbacks when I want to mutate a state.
Which is not something I should do when I have to mutate state, I expect the argument inside the callback (referred as "old" in the examples) to be implicitly typed, or else it would be harder to work with more complex types like string constants.
This bug happens on the type solver beta, and worked perfectly before.
It seems to only happen when the arguments in the callback are from an overload:
typeSetAtom<T>= (newValue: T) ->T-- May be any function maybetypeDispatchAtom<T>= (callback: (old: T) ->T) ->T-- I expect old to be TtypeAtom<T>=DispatchAtom<T>-- Inferred correctlytypeAtom<T>=DispatchAtom<T>&SetAtom<T>-- Not inferred correctly
Here is a replica of the bug by recreating the types seen in Charm:
--!strict-- This type is used in Charm (https://github.com/littensy/charm)-- Placeholder functionlocalfunctionatom(initialValue)
returnfunction(...)
returninitialValueendend-- Set the state using a callback similar to most UI librairies with state managementtypeDispatchAtom<T>= (callback: (old: T) ->T) ->T-- Set the state old fashionned waytypeSetAtom<T>= (newValue: T) ->T-- Get the statetypeMolecule<T>= () ->T-- An example of Charm state, which have 3 ways of interacting with ittypeAtom<T>=Molecule<T>&DispatchAtom<T>&SetAtom<T>localcoins=atom(10) :: Atom<number>locala=coins(10) -- OKlocalb=coins() -- OKlocalc=coins(function(old)
-- old is inferred as unknown here, -- old must be inferred as number-- this can be worked around by explicitly typing old as number-- will even throw a warning telling that the overload argument is not compatiblereturnold+1end) -- Not OK-- c is inferred as a number, OK I guess ?
You can also reproduce the issue by using Charm directly:
--!strictlocalcharm=require("charm")
localcoins=charm.atom(10) --OKlocala=coins() --OKlocalb=coins(10) --OKlocalc=coins(function(old)
-- old is still inferred as unknown, or even "a"returnold+1end) -- Not OK
info
The text was updated successfully, but these errors were encountered:
avion-sandwich-gout-television-asterion
changed the title
Callback arguments not inferred correctly on function overloads
Callback arguments not inferred correctly on function overloads in new solver
Sep 14, 2024
It seems that function overloads themselves makes Luau panic with various features! Just saw it with type literals!
Be sure to throw some unit testing for overloads specifically :<
-- In most cases, it is inferred as string, and not a literal.localgameState=charm.atom("Intermission") :: charm.Atom<"Intermission">gameState("Intermission") -- Inferred as string, not OK!localgameState=charm.atom("Intermission") :: charm.Atom<"Intermission"|"Game">gameState("Intermission") -- Still not OK!localgameState=charm.atom("Intermission"::"Intermission"|"Game")
gameState("Intermission") -- Still not OK!-- Type casting to literals or any is a workaroundlocalgameState=charm.atom("Intermission") :: charm.Atom<"Intermission"|"Game">gameState("Intermission" :: "Intermission") -- OK?!localgameState=charm.atom("Intermission"::"Intermission"|"Game")
gameState("Intermission" :: "Intermission") -- OK?!whiletask.wait(1) dolocalstate=Defs.GlobalState.State-- Is a reference to a charm atomifstate() =="Game" then-- Literal comparison works, OKstate("Intermission") -- Not OKelsestate("Game") -- Not OKendend
I'm using Charm state management library on Roblox Studio, I enabled the long awaited new Beta solver feature.
Although, it now requires me to explicitly cast the argument inside callbacks when I want to mutate a state.
Which is not something I should do when I have to mutate state, I expect the argument inside the callback (referred as "old" in the examples) to be implicitly typed, or else it would be harder to work with more complex types like string constants.
This bug happens on the type solver beta, and worked perfectly before.
It seems to only happen when the arguments in the callback are from an overload:
Here is a replica of the bug by recreating the types seen in Charm:
You can also reproduce the issue by using Charm directly:
info
The text was updated successfully, but these errors were encountered: