Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow function(...: any) to be compatable with function(x: <some type>, y: <some type>, etc) #781

Open
Frityet opened this issue Aug 19, 2024 · 2 comments
Labels
semantics Unexpected or unsound behaviors

Comments

@Frityet
Copy link

Frityet commented Aug 19, 2024

Motivating example:

local interface ICreatable
    create: function(...: any): self
end

local record Person is ICreatable
    name: string
    age: integer
end

function Person:create(name: string, age: integer): Person
    return setmetatable({name = name, age = age}, { __index = Person })
end

Currently this fails because

type signature of 'create' does not match its declaration in Person: different number of input arguments: method and non-method are not the same type
@hishamhm hishamhm added the semantics Unexpected or unsound behaviors label Aug 19, 2024
@hishamhm
Copy link
Member

Teal in general is pretty lax with bivariant function matching, so if we're going with bivariance for functions everywhere, then yes, ideally this should be accepted. (With the caveat of course that bivariant function matching is unsound by design — but a lot simpler to use in general...)

After all, this currently works without complaints:

local type FnType = function(...: any)

local f: FnType

f = function(name: string, age: integer)
end

@hishamhm
Copy link
Member

...and this is a little trickier because generally we've been stricter about redeclarations of record functions. Which is, in general a good thing, because a function implementation not matching its forward-declarations done inside the record is usually a sign of a mistake somewhere.

However, here the "redeclaration" is implicit, because the function field was originally declared in an interface, and it is more likely that non-identical function types are used, as in your example. Gonna think a bit more about this!

That's good feedback, keep it coming!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semantics Unexpected or unsound behaviors
Projects
None yet
Development

No branches or pull requests

2 participants