[mpweiher]

This goes directly at one of the paradoxes of typing.

On the one hand, one of the main benefits of types, and the only one for which there is empirical evidence, is the (automatically checked) documentation effect. For this, the types have to be visible.

On the other hand, not having to type in the types all the time and having them inferred instead seems like a major convenience. For this type types cannot be visible.

Compared to that, the inefficiency of having to do the work over and over seems like a relatively minor issue, though compile times are getting ever more problematic.

So I really like the idea of having types that can be inferred and persisted, though I'd prefer the language to make some room for having "provisional" type annotations, so basically using all sources for getting the types: the user, inference, the running program (dynamic languages can find out about actual types at runtime).

[layer8]

You already can have both, at least in certain contexts: In my IDE, when I write a function call, I can press Alt+Return to have the IDE assign the return value to a new explicitly-typed variable, with the type inferred from the call. Likewise, when for example the return type of the function changes, so that the type of the variable doesn’t match anymore, the IDE highlights that, and again I can press Alt+Return to have the declared type of the variable be updated to match. The point is, in those contexts I never have to actually type the variable type myself.

This is similar to what TFA proposes, and it doesn’t require storage of type information separately from the source code, or in some AST representation. The type information is simply “stored” in the plain-text source code itself, as type declarations/annotations.

I like this approach better than having the IDE merely render inferred type information alongside the source code, because (a) when the type information is part of the actual source code, then it is always visible, e.g. in diffs and source control tools, and (b) like TFA suggests it gives opportunity to interactively resolve type conflicts, and making those decisions “sticky”. With the right IDE tooling, you still wouldn’t need to type the types yourself mist of the time.

[mpweiher]

> In my IDE...

Sounds great! And very close to what I was thinking about.

What's your IDE?

> The type information is simply “stored” in the plain-text source code itself, as type declarations/annotations.

Yes, I think that's the right way to do it. I do believe that there needs to be some way to tell the difference between these three cases:

1. I put the type information there, that's really what I intended

2. The system put the type information there and I okayed it

3. This is what the system currently thinks, no human interaction

However, I believe this just from thinking about it, without having used such a system, so I may be completely wrong.

My background is also dynamically typed systems like Smalltalk, so the state of having no static type information available is also acceptable.

[layer8]

> What's your IDE?

NetBeans. Since Oracle dropped it to Apache, not a lot of work is done on it anymore, but I still cling to it due to a couple of things that IMO it does better than IntelliJ or Eclipse.

Regarding type inference, I prefer to be able to see the types of all variables right away, in all contexts, and therefore I’m not a fan of inferred variable types. It seems to me that those who favor inferred types mostly want to avoid typing (as in “pressing keys”) and problems with refactoring, as opposed to not wanting the types to be visible at all (because they are mostly fine when IDEs do display them). But I believe that can be adequately addressed by appropriate IDE support for inserting/updating type information in the source code itself.

[foota]

An editor can allow seeing types without having them in the code.