To throw one more question into the pot, I'd like to raise the
possibility of wanting typedefs. (To use the old C/C++ term, the latter
also allows a "type alias" syntax that does much the same thing.)
To use an example from the blog post:
function f(List<Entry<int,BlogPost>> $entries): Map<int, BlogPost>
{...}
there need not be an explicit `Map` class; instead something like
`type Map<X,Y> = List<Entry<X,Y>>;`
(to use Rust syntax).
So that one could write `Map<int,BlogPost>` and have it *mean*
`List<Entry<int,BlogPost>>`. The blog example constructed a new Map
given the List of Entries, but with the alias that would become a no-op.
Meanwhile `BlogPost` might itself be an alias for
`StructuredText<\DomDocument>`. Without the aliasing therefore we're
looking at `List<Entry<int,StructuredText<\DomDocument>>` and who is
going to write that over and over? It would muffle use of generics.
I seem to recall that C#'s (or was it Java?) early support of generics
didn't offer any sort of abbreviation mechanism and this lead to long
awkward concrete types that no-one wanted to use.
Calling them "aliases" implies that they're expanded before types are
matched up. If `Wibble<string>` and `Splunge<int>` both ultimately
expand to `Foo<Bar<int>,Baz<string>>` then they would be considered to
be the same type, despite appearances.
Since I expect that type aliases would become a desired feature, I would
hesitate to allow/disallow making type inferences that could block their
introduction. While the alias resolution would be an early stage that
does mean it has to be able to identify any uses of a type in order to
check whether it is a type alias. I can't think of any specific examples
where this would be a problem, but it depends on how they actually end
up looking - they should look like types.
