Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic type aliases #3397

Merged
merged 8 commits into from
Jun 9, 2015
Merged

Generic type aliases #3397

merged 8 commits into from
Jun 9, 2015

Conversation

ahejlsberg
Copy link
Member

With this PR type aliases can be generic. For example:

type Lazy<T> = T | (() => T);

var s: Lazy<string>;
s = "eager";
s = () => "lazy";

type Tree<T> = T | { left: Tree<T>, right: Tree<T> };

var tree: Tree<number> = {
    left: {
        left: 0,
        right: {
            left: 1,
            right: 2
        },
    },
    right: 3
};

interface Tuple<A, B> {
    a: A;
    b: B;
}

type Pair<T> = Tuple<T, T>;

interface TaggedPair<T> extends Pair<T> {
    tag: string;
}

var p: TaggedPair<number>;
p.a = 1;
p.b = 2;
p.tag = "test";

Fixes #1616.

declaredType?: Type; // Type of class, interface, enum, or type parameter
declaredType?: Type; // Type of class, interface, enum, type alias, or type parameter
typeParameters?: TypeParameter[]; // Type parameters of type alias (empty array if none)
instantiations?: Map<Type>; // Instantiations of generic type alias
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to move the typeParameters and instantiations here for classes and interfaces as well? Seems like it would be nice if they were all in one place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will think about it. It is generally more convenient to have them on the Type object because that's what we're operating on in most cases. Getting back to the SymbolLinks from the type requires us to do getSymbolLinks(type.symbol) which adds a bit of overhead.

return unknownType;
}
if (node.typeArguments) {
error(node, Diagnostics.Type_0_is_not_generic, symbolToString(symbol));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this error check is being done in 3 places. Can they be consolidated into one check in getTypeFromTypeReference?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not easily since we fan out based on symbol kind and only during that processing figure out if the type requires type arguments or not. Best we could do is a helper we call in the 3 places, but it doesn't really seem to be worth it.

@JsonFreeman
Copy link
Contributor

👍

ahejlsberg added a commit that referenced this pull request Jun 9, 2015
@ahejlsberg ahejlsberg merged commit acda704 into master Jun 9, 2015
@ahejlsberg ahejlsberg deleted the genericTypeAliases branch June 9, 2015 13:45
david-driscoll referenced this pull request in Reactive-Extensions/RxJS Aug 12, 2015
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants