Only for the simple cases. Consider that there‘s also „anything, but a map with a :name key“ and you‘re thorougly in unrepresentable as typespec territory. You cannot write out all possible maps, which do not have a specific key.
LostKobrakai
2
michallepicki
1.20.rc.0 perf is good so far, compile times are marginally lower compared to 1.19.5. The typechecker highlighted some dead/unreachable code to clean up, and a few missing virtual field declarations on an Ecto schema.
As someone else already mentioned, some tests that were asserting on ArgumentError or FunctionClauseError being thrown started to warn. Maybe there could be situations in which one would want to keep such tests, then it would be good to be able to suppress those compilation warnings somehow.
0
GrammAcc
I actually have this exact use-case in one of my projects. I have some common repo functions for Ecto Schema modules create/1, create!/1, read/1, read!/1, update/2, update!/2, delete/1, and delete!/1 for simple single-row non-join CRUD operations. I have these defined in a Models.Base module and I conditionally define the create, update, and delete operations based on a :read_only option to the __using__/1 macro. I’ve only just started doing this, so it’s not a big deal if I need to figure out an alternative, but I do like having tests in my test suite that assert my read-only schema modules throw an UndefinedFunctionError when calling any of the write operation functions. Just some extra piece of mind in case I forget the read_only: true when defining/updating a schema module. This is not a situation that would be caught by the type system since a call to create!/1 on a should-be-read-only module would only give a typing violation if I correctly remembered to put read_only: true.
Another situation that is more common/realistic is testing program inputs. A static type system can’t protect against invalid data coming into the program at runtime, so if the application takes any kind of user input, having negative test cases to assert bad inputs are handled gracefully is useful. This is a common issue in TypeScript projects because devs get it into their heads that the compiler will catch all the type errors, and then it crashes at runtime due to bad data input by the user. Even in Elixir where we “let it crash”, that only works in embedded applications that don’t have a user looking at the loading bar when the LiveView reloads, so negative tests are good. 
All that being said, I am 100% in favor of better type inference if it doesn’t come with huge performance costs. The more the compiler can do for me without extra code/effort on my part the better. Thanks Elixir Team!
1
sabiwara
Elixir Core Team
Indeed. For the record, in the Elixir repo, these rests are either being removed or tested by using the Process.get(:unused, wrong_arg) hack (examples).
5
josevalim
Creator of Elixir
To add to @sabiwara’s workaround, the type system won’t warn if the program input is within its valid type. For example, if you have a function that expects integers only from 2..26 (like Integer.parse/2), passing an invalid input such as 0 won’t trigger any warning. However, if you give a boolean, then a warning is emitted.
6
BartOtten
No problem. We can always make a map with keys 1..26 so we can catch the issue as the keys are checked.
Jokes aside: any chance this could be done with this type system? Seems not impossible to me (but I have no clue)
(ps. I know it wont safe us from user input, but maybe it can advice to add guards to the outer layer for fail-fast)
0
GrammAcc
Re: negative tests. I’m currently using apply/3 for these UndefinedFunctionError tests since it’s a bit more intentional than a generic get on the module, but I don’t like the idea of using a workaround like that for a defined function where I’m passing in a boolean or string instead of an integer.
It’s actually a very common error if the FE is standalone JS and not server rendered for someone to accidentally call .toString() on a number before serializing, and then the JSON field gets parsed as "1” instead of 1 on the BE. For most applications, this isn’t a big deal, but I’ve ran into this when writing a very strict input validation layer before, so I think having a way to selectively disable type inference for test modules is a good feature to have. I don’t think we should have @type-ignore pragmas or anything that could be used anywhere we want cause that would encourage type hell, and Elixir’s dynamic() is much better than other langague’s any, so I don’t think we will need it in application code.
Some code is just intentionally written to violate application constraints though. Namely negative test cases.
Hopefully, fuzz testing and simulation testing gets easier to implement at small scales, so this problem would eventually go away, but for now, a workaround in the language or library layers instead of the user’s test code would be ideal.
Maybe this could be solved with a custom mix compiler for ExUnit modules that disables type inference (but not type checking in general)?
1
GrammAcc
Would be great if the language tooling could somehow encourage this practice. I always advocate for doing all input parsing as close to the application boundary as possible at work and in community projects. It saves so much time later on to know that any data structure that makes it into the service layer is valid.
Not sure how that would be detected though. Maybe more of a linter thing than compiler warning since it’s more of a code style/pattern issue than an actual technical problem with the code?
0
michallepicki
I agree Process.get “feels” like a hack, but maybe a dynamic/1 function helper that hides a type of a value would be fine?
2
GrammAcc
It would work. Personally, I dislike constructs that blur the lines between the type annotations and runtime code/checks. I would prefer a solution that doesn’t require me to change any of my application or test code since this is related to inference in the first place, but that’s just my preference. I dunno what the popular opinion on that is. I just know I really like how Python clearly separates static types from runtime behavior and TypeScript gets really messy when it’s unclear which context some code is in. For example, accessing object attributes on an Enum in typescript is pretty messy cause it changes the context of the code from the compile-time type to the runtime object implicitly without clear indication in the syntax.
0