IssueRaiser

Support some non-structural (nominal) type matching

Proposal: support non-structural typing (e.g. new user-defined base-types, or some form of basic nominal typing). This allows programmer to have more refined types supporting frequently used idioms such as: 1) Indexes that come from different tables. Because all indexes are strings (or numbers), it's easy to use the an index variable (intended for one table) with another index variable intended for a different table. Because indexes are the same type, no error is given. If we have abstract index classes this would be fixed. 2) Certain classes of functions (e.g. callbacks) can be important to be distinguished even though they have the same type. e.g. "() => void" often captures a side-effect producing function. Sometimes you want to control which ones are put into an event handler. Currently there's no way to type-check them. 3) Consider having 2 different interfaces that have different optional parameters but the same required one. In typescript you will not get a compiler error when you provide one but need the other. Sometimes this is ok, but very often this is very not ok and you would love to have a compiler error rather than be confused at run-time. Proposal (with all type-Error-lines removed!): ``` // Define FooTable and FooIndex nominal FooIndex = string; // Proposed new kind of nominal declaration. interface FooTable { [i: FooIndex]: { foo: number }; } let s1: FooIndex; let t1: FooTable; // Define BarTable and BarIndex nominal BarIndex = string; // Propose

Posted by iislucas on Jul 22, 2014, 11:52 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.9,500 issues0 comments

support (Software)

Support some non-structural (nominal) type matching

iislucasJul 22, 2014, 11:52 PM

Proposal: support non-structural typing (e.g. new user-defined base-types, or some form of basic nominal typing). This allows programmer to have more refined types supporting frequently used idioms such as: 1) Indexes that come from different tables. Because all indexes are strings (or numbers), it's easy to use the an index variable (intended for one table) with another index variable intended for a different table. Because indexes are the same type, no error is given. If we have abstract index classes this would be fixed. 2) Certain classes of functions (e.g. callbacks) can be important to be distinguished even though they have the same type. e.g. "() => void" often captures a side-effect producing function. Sometimes you want to control which ones are put into an event handler. Currently there's no way to type-check them. 3) Consider having 2 different interfaces that have different optional parameters but the same required one. In typescript you will not get a compiler error when you provide one but need the other. Sometimes this is ok, but very often this is very not ok and you would love to have a compiler error rather than be confused at run-time. Proposal (with all type-Error-lines removed!): ``` // Define FooTable and FooIndex nominal FooIndex = string; // Proposed new kind of nominal declaration. interface FooTable { [i: FooIndex]: { foo: number }; } let s1: FooIndex; let t1: FooTable; // Define BarTable and BarIndex nominal BarIndex = string; // Propose

Comments (0)

No comments yet. Start the discussion.

Comment on this issue