Type aliases and other changes in language specification

[Anders Hejlsberg (ahejlsberg)]

Changes in this PR:

• New section on Type Aliases.
• Union Types are now a separate kind of type, distinct from object types.
• The concept of Apparent Type is replaced with Apparent Members.
• Subtypes and Supertypes and Assignment Compatibility use Apparent Types.

[Adam Freidin (sparecycles)]

Could you clarify why a type is allowed to reference a union of a primitive and an anonymous type but not an anonymous type by itself?

typeText=string|{text: string};// <-- example in spectypePoint={x: number;y: number;};// <-- explicitly disallowed by spec

[Anders Hejlsberg (ahejlsberg)]

A type alias for an anonymous object type literal:

typePoint={x: number;y: number;};

would be almost the same as an interface declaration:

interfacePoint{x: number;y: number;}

The subtle differences include:

• An interface is open-ended (can have multiple declarations), a type alias is not.
• You can derive from and implement an interface, but neither is possible with an alias for an anonymous type.
• In error messages and quick info, an interface is displayed by name whereas a type alias is displayed by structure.

We feel that the confusion caused by these differences are better avoided.

[Anders Hejlsberg (ahejlsberg)]

I should add that an alternative to the error would be to just treat type alias declarations for object type literals as equivalent to interface declarations. We discussed doing that, but we thought it would be odd for such type alias declarations to merge with other type alias or interface declarations for the same name. But disallowing merging would then again make them different from interfaces.

Anyway, I could be persuaded we should just say type aliases for object type literals are exactly equivalent to interface declarations, merging and all.

[Adam Freidin (sparecycles)]

I understand that there are subtle semantic differences (which could be employed to create an interface type which can't be extended) but I feel we don't need to have an arbitrary restriction in order to sidestep some perceived difficulty down the line.

All I can do is urge you to reconsider.

If you don't reconsider, I can always work around the restriction by defining

typePoint={x: number;y: number;}|{x: number;y: number;};

😉

[Ryan Cavanaugh (RyanCavanaugh)]

We didn't really like the carve-out for object types either, but it seems better than the alternatives. Are there specific use cases where you want to write type Point = { ... } instead of interface Point { ... }? If so, which semantics do you want? Or is it just an objection to the restriction on philosophical grounds?

[Adam Freidin (sparecycles)]

Mainly philosophical, given that it's supported as part of a union.

I don't think type aliases should be extendable. In that sense type Point = { ... } should not be the same as interface Point { ... }. There's no reason to special-case the non-union case to be the same as the named interface case.

Another thing to consider is function types:

typefun=()=>number;// allowedtypefun={// not allowed?(): number;(_:string): string;};

By disallowing the second one, the ability to declare overloaded function type aliases is restricted to exported interfaces only.

[Ryan Cavanaugh (RyanCavanaugh)]

The danger is that if we don't make type Point = { ... } the same as interface Point { ... }, then you can't say interface P extends Point or class P implements Point (only named types can be used in heritage clauses). It's likely that a lot of .d.ts authors won't understand the distinction and will blindly use type without realizing they're making it a pain to use the type in certain ways.

That's the same reason we allowed shorthand function types as alias targets -- implementing or extending those types would be very rare compared to object types with properties.

[Adam Freidin (sparecycles)]

I understand your reasons. I still disagree.

I have to argue that .d.ts authors would be, in general, more technical than .d.ts users, and could be trusted to use type v.s. interface effectively.

But I don't think I can contribute any more to this discussion. Thanks for your time.

[Anders Hejlsberg (ahejlsberg)]

Adam Freidin (@sparecycles)Ryan Cavanaugh (@RyanCavanaugh) I do agree it is an odd restriction and one that we're not particularly fond of. I'm starting to think we should just allow it and note the differences (and their consequences) in the Language Specification.

[Noel Abrahams (NoelAbrahams)]

The original objection to this was that if we wanted to annotate the parameter in the following function:

functionfoo(point: {x: number;y: number}){}

with the introduction of type aliases, there would be three ways of annotating point:

// A. Using an interfaceinterfacePoint{x: number;y: number;}// B. Using typeof with type aliasesvarpoint: {x: number;y: number};typePoint=typeofpoint;// C. Directly declaring with type aliasestypePoint={x: number;y: number};

All three methods of declaring Point are equivalent for the _use-case outlined above_, because Point is not intended to be implemented by any class. The extensibility of Point is also not an important consideration for in-house code, because it will just be a case of changing it to an interface as required.

My specific objection is that in an organisation, when there is more than one way to accomplish the same thing, we end up having half the people using one mechanism and the other half the other. Then we have situations of people correcting each other's coding styles in an endless death spiral 😃 .

This is of course why linters exist, but I was arguing for the problem to be resolved at source.

However, in this case, since only the third mechanism is prohibited, it doesn't really achieve the desired result in any case.

My preference is for type aliases to be restricted to union and tuple types:

typeu=string|number|{n: string};typet=[number,number];types=string;// error

We have lived without type aliases for two years now without a significant demand from the community.

[Adam Freidin (sparecycles)]

I think we have to ask ourselves, are we adding type aliases to fill a particular need with union and tuple types, or are we extending typescript with a new feature?

[Anders Hejlsberg (ahejlsberg)]

I think we just have to accept the overlap between interface declarations and type alias declarations. The key observation here is that an alias is _exactly_ the same thing as writing the type it aliases, and since anonymous object type literals overlap with interface declarations, then so do aliases to object type literals. At the end of the day, a lot of this comes down to the fact that we have a structural type system and that there will always be multiple ways to write a particular type.

I completely agree that it would ideal not to have this overlap. However, artificial restrictions seem like a cure that's worse than the disease, so I think we should drop them for now.

[Anders Hejlsberg (ahejlsberg)]

Updated Type Alias section in the spec to describe differences between interfaces and type aliases for object type literals.

[Cyrus Najmabadi (CyrusNajmabadi)]

Anders Hejlsberg (@ahejlsberg) The updated section looks great!

[Daniel Earwicker (danielearwicker)]

How about type alias with type parameters?

type prop<T> = T | () => T;
interface Foo {
name: prop<string>;
age: prop<number>;
whatever: prop<Bar>;
}
function fetch<T>(p: prop<T>) {
return (typeof p === "function") ? p() : p;
}

[Ryan Cavanaugh (RyanCavanaugh)]

Daniel Earwicker (@danielearwicker) Can you log a separate suggestion issue for that? Thanks!

[Daniel Earwicker (danielearwicker)]

Logged #1616 Type aliases requiring type parameters