Are typespecs deprecated? (Reddit thread answer from Jose)

Chat / Discussions
1

I discovered this link on bluesky, and it was a bit of an accidental thing, but I think it contains some nice information that’s worth checking out if you’re interested in the type checking future of Elixir.

https://www.reddit.com/r/elixir/comments/1i77ia9/comment/m8il2ho/

7 Likes
2

@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!

1 Like
3

One thing I don’t understand from Jose’s comment is this:

It calls modules/functions defined in the same project. We have no plans to introduce the [this] option. It is not complex to do, we are just not sure it will provide good UX, specifically when it comes to compilation times. And then we would rather focus on type annotations rather than inferring everything. Note none of the above apply to actual type checking, only the inference bits.

Does that mean there will be no type inference or checking within the same project?

4

it actually says in the part you quote

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

2 Likes
5

i think the semantics for @type @typep and @opaque will never go away once its used for docs, even in erlang ecosystem… deprecation of those things seems to be a big departure of the tools of the ecosystem, i’d think it would happen on a possible elixir 2.0 at some point.

1 Like
6

Right but that means you can’t do much type checking if there are no explicit type annotations in the project code right?

Maybe I’m misunderstanding, but it seems like the following would happen:

defmodule MyApp do
  def foo(x), do: IO.puts(x)

  def bar(), do: foo(123)

  def baz(), do: IO.puts(123)
end

In this example, the compiler would throw a compilation error on baz but not on bar because the type of foo is not being inferred therefore it doesn’t know that foo(123) is not valid

7

Type inference will work inside a module, not across modules. If I understand correctly, you can read more about it here: elixir/lib/elixir/pages/references/gradual-set-theoretic-types.md at main · elixir-lang/elixir · GitHub

1 Like
8

I tried to search for an issue for this on github, but couldn’t find any immediately. Did you report this problem?

1 Like
9

Except that I checked it on a project I currently work on, I wrote this from memory … I have read about it years ago and obviously don’t remember the source. :sweat_smile:

10

If you have a real issue, I’d say open a bug report. That’s the way issues get fixed :slight_smile:

11

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.

7 Likes
12

I found what I remembered about macros. Looks like the issue is still open:

Regarding the weird behaviour about 0% coverage it’s about a confusing coveralls defaults and it could be fixed simply by creating a file called coveralls.json with following content:

{
  "coverage_options": {
    "treat_no_relevant_lines_as_covered": true
  }
}

In my opinion those files should be by default skipped i.e. at the bottom of the report there should be a note that x files were skipped due to no relevant lines found. The other suggested solution is to print it such files with N/A, - or similar result. Of course it does not affect the final score, but the default look really weird and are very confusing …

Simply think that you realised such detail and see an open issue many years ago and after years you found that support for it has been added with some option. :sweat_smile:

Anyway, the coverage tool is limited a lot especially if you are creating using a lot of macros.

1 Like