V: Support type aliasing

[neverix]

Right now there's no way (AFAIK) to alias a type without creating a new, distinct one. This leads to confusion (#213, #983) and problems when refactoring code.

One solution for this is using D's alias. I propose adding this keyword and using it for true type aliases with implicit conversion (like in Go). One use for this would be gradual type repair, explained in the aforementioned issue and this article.

The same syntax could also be used for aliasing consts and modules.

Usage example:

type Int int

fn f() Int {
  return 5
}

currently fails with the error expected type Int, but got int. Fixing it requires replacing the return value with Int(5):

type Int int

fn f() Int {
  return Int(5)
}

With the proposed alias keyword, this would work fine:

alias Int int

fn f() Int {
  return 5
}

This feature might be used for making byte and int values true aliases.

There is an alternative syntax (borrowed from Go):

type Int = int

fn f() Int {
  return 5
}

[ciubotaru]

What is the benefit of having many names for one thing?

[neverix]

This is discussed in depth in the Golang issue and article mentioned above.

Basically: when moving types/functions from one module to another, the maintainer needs to consider existing code breakage. The types must be interchangeable in the old and new API so that code using the module doesn't break while migrating to the new one. This was very hard to do in Go when they moved os.Error to errors. They ended up adding a compiler hack specifically for this issue, which is impossible for external libraries.

[baziotis]

+1 on the support of type aliasing. I was about to create an issue that type aliasing doesn't work but then was referred to this issue. First of all, if not for type aliasing, I don't understand where type helps. I could not find any documentation either.
@neverix FWIW, type aliasing is not trivial to be supported.

[Delta456]

+1 for this

[medvednikov]

Fixed, your original example works now.