please tell me we’re getting rid of Typespecs in favor of the new syntax in long term? I’d hate to see both syntaxes in use, my brain can barely understand Typespecs as they are
hubertlepicki
dimitarvp
I can’t see how that’s different from today, only you don’t have to put any extra code, you just let the unexpected value slip and get a case clause error at runtime.
Been reading the last replies carefully but I am starting to lose the thread of thought; I got no idea what the other posters (you included) have in mind for the theoretical ??? thingy exactly.
adw632
adw632
In fact I feel quite certain that where a catch all “any” case is detected which is provably redundant because all the other cases exhaustively handle the set of possible values, the compiler should complain.
This will help prevent some bad defensive nanny coding idioms taking hold and occluding detection of future problems as code evolves.
Elixir is not like other languages where the developer must be sure to handle every eventuality, as we have a runtime that handles things we didn’t know about at design time. The last thing we want are idioms that occlude future knowledge as code evolves, and hide problems that we could have detected and handled at design time in future revisions of our system.
josevalim
Creator of Elixir
Let’s see if I got it right. Your concern is that something like _ -> ??? may promote defensive code that is actually worse than today because:
- It doesn’t help at compile-time
- It is more verbose than today with no benefits on runtime or intent
You are actually ok with :bar -> ???. But adding something like ??? should come with the caveat that it should not be used in pokemon clauses. If so, that’s a good point and we are in agreement.
adw632
Yes I agree that communication and intents is very important.
Handling the case :baz -> ??? may be due to many factors, some specific state passed to some_func() that is now permitted but previously wasn’t, or it could just be a more nuanced return type but either way it is an API surface change/versioning and that is a topic that is also worthy of another whole conversation.
This example however goes well beyond types because here we are looking at value semantics, even a static typed language won’t automatically handle a new case.
That said, the compiler should identify a non exhaustive case expression, then it is up to the developer how they wish to handle it, either explicitly handling the new cases, or making sure their inputs conform to the possible return value cases they are prepared to handle or as the very last resort, declaring a catch all so the compiler accepts this without generating further noise.
Once the compiler is silenced with a catchall clause the developer forever gets the silent treatment from the compiler.
This means a change from some API v1.0 to v1.1 may catch a few things but v1.1 to v1.2 will silence potential issues due to catch alls. This is why I don’t think defensive catch all approaches are a good idiom in the face of changes and explicit is far better for being defensive so you can detect and then handle future return values as code evolves, especially changes in external dependencies.
josevalim
Creator of Elixir
I would say there is another aspect here: communication between humans and your future self. Imagine that you find this code:
case some_fun() do
:foo -> ...
:bar -> ...
end
And some_fun may also return :baz. There are at least two possible interpretations:
- You know it could return
:bazbut you don’t care - When you implemented it,
:bazwas not a possible return value
If you add something such as :baz -> ???, then you are removing the ambiguity and explicitly encoding a decision. Which is why some interpret it as augmented let it crash.
Those are somewhat orthogonal discussions. The type system is expressive so we can indeed surface most of these decisions up. We hope that, in many scenarios, the type system will know exactly the subset of return values that match your input. So it isn’t like you will have to handle those decisions everywhere. I think this is an important nuance that may be getting lost in the conversation. This discussion is more about when the return values are based on runtime behaviour and then there is no way to disambiguate and surface up at compile-time.
adw632
Thanks for your post.
The answer depends on the context. The example of handling all possible case values using something like ??? or !unreachable, !oops vs only handling what you care about have practically identical runtime behaviour.
However at compile time if an error/warning indicates that some case expression is “not exhaustive” the developer may likely see the problem being the case expression rather than much further up the call graph where input ought to have been sanitized earlier. You definitely want to catch these occurances and not silence them prematurely by being exhaustive BECAUSE the problem actually lies elsewhere.
However if the case expression (or some function call) actually forms part of the role of santizing values from boundary layers then you still want the heads up from the compiler, however you may choose to silence these by handling the missing case explicitly (catching actual sanitization problems, missing values, typos etc) OR you may want to express that “its ok I don’t want or need to write more code to silence the compiler and I really want to let it crash here, please don’t complain here again”.
We have discussed some notions for expressing that something should never happen however it is not quite there yet IMO because we probably do need to handle “stfu compiler” from the caller site where we don’t want to write more code and we acknowledge that we want it to crash.
What I don’t want is defensively coding the sad path for every function signature and every case statement in the core logic of my app (aka “pipeland”) nor do I want every hex utility package I include using “defensive” idioms as “best practice” because it will prematurely silence problems that ought to be handled by the caller at a layer or more above.
If we decide that we do wish to explicitly handle cases and function signatures as a programmer aid (perhaps because of deprecations), then I think we do need a language feature to signal that although we are handling this function signature or case expression we still want any call graph that arrives here to be flagged as a problem on the CALLER, and ideally the entire call graph being implicated starting from the root so that the origin of the problem is handled as far up the call graph as possible.
For this reason the compiler should list the call graph paths that are implicated in the issue of not meeting the supported type and value constraints.
adw632
Typically a context module is where things can fail..
Santizing external user input and applying it to Ecto repo queries or changesets for the external database or interfacing with something else external.
stevensonmt
I apologize for the dumb question, but in terms of architecture, where is the boundary layer in a phoenix app? My assumption is that your example fits with the statement:
but that if the Phoenix team introduced some means of overriding things such that calling handle_event that raises an error for no value or no type matching in the case statement silently does some mitigation to prevent a crash then it would fall into
I don’t really have any idea how the Phoenix team (or anyone else, I don’t mean to pick on them) could implement such a strategy, but I think that is @andrewh’s concern. But I also think maybe I’m misunderstanding.