thunderseethe

Yeah I was just wrong here. I was under the impression clang had a concept of a request the same way Swiftc does and that is just not true. That's my bad!

What are you calling bidir, if the introduction of unification means its no longer bidir?

> You can get localised unification but bidir as a whole like in Rust but you lose most of the advantage of unification.

Could you expand on this? I do not follow. You can create a bidir system that never requires annotations and uses unification to infer all types in the style of Haskell or OCaml. It is not often done because people are coming around to the idea that global type inference causes spooky action at a distance, but nothing prevents it from working.

> I maintain that what the article calls HM is trully unification

In some sense I think HM == unification because you can't really implement HM without unification. The first time a type variable encounters another type you'd be stuck.

In general I agree with what youre advocating for. Languages should require annotations on function parameters and return types and most top level definitions. But even if you only infer types locally you'll still want unification to do it well. Without unification local inference will hit annoying edge cases where you have to add otherwise unnecessary annotations

> The real question is unification vs bidir

Quite the opposite, imo. Unification does not exclude bidir and the two fit together very well. You can have one system with both Unification and bidir and get all the advantages of both.

> I wonder if this is a reference to "I need you to understand that people don't have conversations where they randomly recommend operating systems to one another"

It is!

> my understanding is that there are areas where you can use bidirectional typing (e.g. languages that have subclasses) where HM style type inference might become undecidable

There are! Afaik most languages end up with a bidirectional system in practice for this reason. Haskell started out HM and has shifted to bidir because it interacts better with impredicative types (and visible type applications). Bidir can handle fancy features like subtyping and all sorts of nifty stuff.

This is probably my biggest regret with this article. Much earlier and much more prominently I should've explained that the title is a play on a running joke Andreas Rossberg includes in a couple of his talks "wasm does not stand for webassembly", poking fun at how they named it that to get funding, but always intended it for a more general use case.

I have a nod to it, as you point out, but I think its buried so far beneath the fold most folks have checked out and written it off by then. Live and learn .