As you can see, I am pulling a string from a table of strings called Exceptions and formatting the string according to the Operator used; all of them are consistently typed as a string. But somehow, the .format function doesn’t recognize any arguments being passed when obviously, Operator is an argument being passed.
I’ve tried bombarding it with typesets (which in retrospect, obviously won’t work but I did it for whatever reason), and wrapping the function which got rid of the error on that line, but moved the error to the wrapper function. (Maybe proving that this is a problem inherent with the .format function)
I’ve looked it up but no one else seems to have made a post similar to mine. I am using the new Luau type solver so, maybe it has to do something with that?
I’m seeing that you are using %q in your text, although I don’t believe that that is valid in roblox formatting. Looking in the documentation furthered this.
Please don’t mistaken me as someone who isn’t well-versed with the library. I have worked with string manipulations many times before.
Besides, that’s not what the type error is pointing out, it says that the function has not received any arguments when it obviously has. Furthermore, I don’t think a type solver would or should be designed in a way that cares about the subtleties of a string at all nor should it depend on the context it is being used on.
Oh and undocumented doesn’t always mean that it’s not an official feature, some things just slip out of documenter minds. I’ve seen this pattern being used in other works.
It wouldn’t hurt but it also wouldn’t make a difference because we know what the operators are. The operators come from a table full of strings defined by the user, as seen here. Just as one would expect, it prints out the same things it looped through.
As you can see, here. there are two cases where string.format is being used but only one really produces a type error. With the ..self.QS present, the type solver is not able to detect any arguments and errors. Without it, it still errors, but now it complains how it only accepts 2 arguments even when the function explicitly tells us that it accepts a variadic.
I think this is very convenient for things that the typechecker hasn’t been able to do before. But there’s a bunch of confusing things that just don’t make sense (thinking a table’s type is different when in an if-block), and this is one of those things.
I would wait it out. If you know the code works, you can ignore/comment it, make an issue about this scenario, or just disable it (File>Beta Features).
I am aware. But I’ve been using the new type solver for quite some time now and I’m afraid that newer projects I’ve been working on that relies on the type solver would error out, so I’ll just wait for a fix.
Ooh, do you mean something like Typescript’s @ts-ignore to ignore the type errors in the next line? If so, how can you do so?