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

type checking return term() #107

Closed
gomoripeti opened this issue Dec 9, 2018 · 2 comments
Closed

type checking return term() #107

gomoripeti opened this issue Dec 9, 2018 · 2 comments

Comments

@gomoripeti
Copy link
Collaborator

I believe type checking the return value of a function which is spec-ed to return term() should always pass (the same way as being spec-ed to return any()) as every type is a subtype of term(). (this is of course an under-specification from the side of the user)

This works fine for certain expressions where the subtype function is used, eg:

-spec return_float() -> term().
return_float() -> 1.23.

-spec return_string() -> term().
return_string() -> "asd".

However where the check uses the expect_*_type family of functions, type checking fails, because these helper functions don't allow term().

-spec return_tuple() -> term().
return_tuple() -> {1, 2}.

-spec return_list() -> term().
return_list() -> [1, 2].

-spec return_record() -> term().
return_record() -> #rec{}.

yields:

The tuple on line 48 does not have type term()
The expression [1,2] on line 51 does not have type term()
The record #rec on line 54 is expected to have type term().

I'm willing to fix this, if this is indeed a bug, however I'm not sure if the expect_*_type functions should be extended, or rather do_type_check_expr_in should short-circuit for term() the same way as for any()?

@josefs
Copy link
Owner

josefs commented Dec 10, 2018

This is indeed a bug! I think it'd be best if the expect_*_type functions were extended to handle term().
Thanks!

@josefs
Copy link
Owner

josefs commented Dec 19, 2018

Fixed by #113

@josefs josefs closed this as completed Dec 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants