If you don’t have a type signature, we will infer one for you and use it when type checking remote calls. The inferred signature can understand everything about your code, except calls to other modules in the same project. So they are a good approximation and give valuable benefit for whoever wants to be lazy and not type anything. If you want proper type checking, then you have to write the signatures for your public functions.

it actually says in the part you quote

type check will be done whenever you do the annotations, inference only for external stuff.

@tcoopman Keep in mind that changes even in nearest Elixir version would not affect whole community immediately. There would be months if not years of delay. That’s because many projects supports few Elixir versions back, so at best they may have both systems implemented (assuming the new one would not cause compilation errors in earlier versions) and in worst case they would replace new system after a longer time.

If said change would happen in ecto, phoenix, credo, excoveralls and many, many other most popular packages then the change to new type system would be rapid as there would be no sense to maintain both systems in long term especially if they are completely different while covering same things.

That’s said … new projects or those who focused on support latest Elixir versions would most likely switch to new system immediately as long as @type, @typep and @opaque would not be hard deprecated (if any). Unlike in packages shared on hex those projects would not cause problems with other projects and if they do (umbrella apps, internal dependencies) then most likely all related projects would have such changes soon as well.

However it would progress I would take a deep look from the very beginning as I wrote tons of typespecs and I’m willing to migrate asap (even if it would be 100% manual). I only wonder if Elixir core team plans to work in future on cover replacement. Similarly to dialyzer coverage does not works as good as it could (especially with macros) and modules with only types and struct definitions that have 0 relevant lines which is equal to 0% coverage!