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
Is your feature request related to a problem? Please describe.
gen_server:call/2, call/3, cast, etc. don't have specs, afaict, which makes type-checking these calls more difficult.
There are spec-like things written in the XML used to generate documentation. These could be adapted as a starting point for psecs.
Describe the solution you'd like
specs, which unfortunately would have to have a lot of term()s, because the type language doesn't allow us to express the ways in which the return of (for example) call(ServerRef, Request) -> Reply is dependent on callback implementations in the process that corresponds to ServerRef.
Describe alternatives you've considered
no specs–type checkers would have to have their own logic for connecting behavior functions to callbacks
AND/OR extending the type language to express the relationship between behavior types and callback types. Adding term()y specs now doesn't preclude a more precise solution in future.
Additional context
Happy to make a PR–I have some of these typed up already, based on adapting specs from the xml used to generate documentation.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
gen_server:call/2
,call/3
,cast
, etc. don't have specs, afaict, which makes type-checking these calls more difficult.There are spec-like things written in the XML used to generate documentation. These could be adapted as a starting point for psecs.
Describe the solution you'd like
specs, which unfortunately would have to have a lot of
term()
s, because the type language doesn't allow us to express the ways in which the return of (for example)call(ServerRef, Request) -> Reply
is dependent on callback implementations in the process that corresponds toServerRef
.Describe alternatives you've considered
term()
y specs now doesn't preclude a more precise solution in future.Additional context
Happy to make a PR–I have some of these typed up already, based on adapting specs from the xml used to generate documentation.
The text was updated successfully, but these errors were encountered: