Type Annotation Overview

[00:00:00]
>> Richard Feldman: So, we're gonna talk about four different types of type annotations, or sort of four categories. One is annotating primitives. Talk about annotating type parameters, type aliases, and typing functions. All right, so let's start with a plain old declaration, of the type we've seen many before. So, username = the string rtfeldman.

[00:00:22]
So something I could do here is I could, if I wanted to, I could add a sort of comment here that says query or username, this thing right here is a string. Another way I could do this is I could write it like this. This is a type annotation that says this username is a string.

[00:00:40]
The bottom one is more of reliable in the sense that the compiler will enforce it. It will actually check to see if this username value is in fact a string. One of the things about comments is they can get out of date. For example, maybe this thing used to be called query and I renamed it to username but I forgot to update the comma, the comment rather.

[00:01:02]
I didn't actually intend for this to be this way. I actually just forgot to update it on the slide, which works out in a funny way of demonstrating the point. If you have documentation that can get out of date, chances are it's going to get out of date.

[00:01:14]
We're human, we make mistakes. One of the nice ways that Elm's compiler can help us out is it can actually fix things like this for us. It can catch them and give us an error message, if we try to build our code and this is out of date.

[00:01:26]
So as we've seen, we don't need these. I did Java programming for many years, sort of earlier in my career. And I would have to write out type annotations all the time, whereas Elm does type inference. It figures out what all they types are, and it will tell us about errors regardless of whether or not we actually put these annotations in there.

[00:01:44]
They're optional, but they can be a nice form of documentation. And it's usually considered best practice to use them at least for your top level declarations. If you're doing them inside a let, no real need. But at least at the top level, functions and things like that. Generally speaking, it's a good idea to annotate them just as a form of documentation for whoever comes across the code next.