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
There's a strong argument that only contracts at a module's boundaries should have contracts (or tests). But the author has stated: "My goal is to build a system that allows you to validate any elixir data at any point in your stack."
My workaround for now is to make all my functions public.
PS: Take my flood of issues as evidence that I'm loving the library.
The text was updated successfully, but these errors were encountered:
In #29 we introduce foundation for contract reflection. The plan for reflection is to start it as private API, if it becomes public the question would be whether a contract for a private function should be public. I can see both sides of this: if reflection would be used as just a list of contracts (to e.g. re-use a contract elsewhere) then +1 for this; on the other hand if reflection would be used to see capabilities of the given module (what functions it has and what they require/provide) then imho it should be private, perhaps with a @contractp.
You can't specify a contract for a private function.
For example:
Gives the error:
There's a strong argument that only contracts at a module's boundaries should have contracts (or tests). But the author has stated: "My goal is to build a system that allows you to validate any elixir data at any point in your stack."
My workaround for now is to make all my functions public.
PS: Take my flood of issues as evidence that I'm loving the library.
The text was updated successfully, but these errors were encountered: