Support some non-structural (nominal) type matching

[iislucas]

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; // Proposed new kind of nominal declaration.
interface BarTable {
  [i: BarIndex]: { bar: string };
}
let s2: BarIndex;
let t2: BarTable;

// For assignment from base-types and basic structures: no type-overloading is needed.
s1 = 'foo1';
t1 = {};
t1[s1] = { foo: 1 };

s2 = 'bar1';
t2 = { 'bar1': { bar: 'barbar' }};

console.log(s2 = s1); // Proposed to be type error.
console.log(s2 == s1); // Proposed to be type error.
console.log(s2 === s1); // Proposed to be type error.

t1[s2].foo = 100; // Gives a runtime error. Proposed to be type error.
t1[s1].foo = 100;

function BadFooTest(t: FooTable) {
  if (s2 in t) {  // Proposed to be type error.
    console.log('cool');
    console.log(t[s2].foo); // Proposed to be type error.
  }
}

function GoodBarTest(t: BarTable) {
  if (s2 in t) {
    console.log('cool');
    console.log(t[s2].bar);
  }
}

BadFooTest(t1); // Gives runtime error;
BadFooTest(t2); // No runtime error, Proposed to be type error.
GoodBarTest(t1); // Gives runtime error; Proposed to be type error.
GoodBarTest(t2);

[RyanCavanaugh]

Is there a better keyword here than "abstract" ? People are going to confuse it with "abstract class".

+Needs Proposal

[iislucas]

w.r.t. Needs Proposal: do you mean how to implement it? For compilation to JS, nothing needs to be changed. But would need internal identifiers for new types being introduced and an extra check at assignment.

[samwgoldman]

Regarding a name, what about "nominal" types? Seems pretty common in literature.

[RyanCavanaugh]

We're still writing up the exact guidelines on suggestions, but basically "Needs Proposal" means that we're looking for someone to write up a detailed formal explanation of what the suggestion means so that it can be more accurately evaluated.

In this case, that would mean a description of how these types would fit in to all the various type algorithms in the spec, defining in precise language any "special case" things, listing motivating examples, and writing out error and non-error cases for each new or modified rule.

[iislucas]

@RyanCavanaugh Thanks! Not sure I have time for that this evening :) but if the idea would be seriously considered I can either do it, to get someone on my team to do so. Would you want an implementation also? Or would a clear design proposal suffice?

[danquirk]

@iislucas no implementation is necessary for "Needs Proposal" issues, just something on the more formal side like Ryan described. No rush ;)

[zpdDG4gta8XKpMCd]

There is a workaround that I use a lot in my code to get nominal typing, consider:

interface NominalA {
   'I am a nominal type A, nobody can match me to anything I am not': NominalA;
    value: number;
}

interface NominalB {
   'I am a nominal type B, mostly like A but yet quite different': NominalB;
   value: number;
}

// using <any> on constructing instances of such nominal types is the price you have to pay
// I use special constructor functions that do casting internally producing a nominal object to avoid doing it everywhere
var a : NominalA = <any>  { value: 1 };
var b : NominalB = <any>  { value: 2 };

a = b; // <-- problema

[iislucas]

Neat trick! Slight optimization, you can use:

var a = <NominalA>  { value: 1 };
var b = <NominalB>  { value: 2 };

(Slightly nicer/safer looking syntax)
[Shame it doesn't work for creating distinct types for string that you want to be indexable]

[basarat]

@Aleksey-Bykov nice trick. We have nominal Id types on the server (c#) that are serialized as strings (and we like this serialization). We've wondered of a good way to do that without it all being string on the client. We haven't seen bugs around this on the client but we still would have liked that safety. Based on your code the following looks promising (all interfaces will be codegened):

// FOO 
interface FooId{
    'FooId':string; // To prevent type errors
}
interface String{   // To ease client side assignment from string
    'FooId':string;
}
// BAR
interface BarId{
    'BarId':string; // To prevent type errors
}
interface String{   // To ease client side assignment from string
    'BarId':string;
}


var fooId: FooId;
var barId: BarId;

// Safety!
fooId = barId; // error 
barId = fooId; // error 
fooId = <FooId>barId; // error 
barId = <BarId>fooId; // error

// client side assignment. Think of it as "new Id"
fooId = <FooId>'foo';
barId = <BarId>'bar';

// If you need the base string 
// (for generic code that might operate on base identity)
var str:string;
str = <string>fooId;
str = <string>barId;  

[Steve-Fenton]

We could look at an implementation that largely left the syntax untouched: perhaps we could add a single new keyword that switches on "nominality" for a given interface. That would leave the TypeScript syntax largely unchanged and familiar.

class Customer {
    lovesUs: boolean;
}

named class Client {
    lovesUs: boolean;
}

function exampleA(customer: Customer) {

}

function exampleB(customer: Client) {

}

var customer = new Customer();
var client = new Client();

exampleA(customer);
exampleA(client);

exampleB(customer); // <- Not allowed
exampleB(client);

So you can use a Client where a Customer is needed, but not vice versa.

You could fix the error in this example by having Customer extend Client, or by using the correct named type - at which point the error goes away.

You could use the "named" switch on classes and interfaces.

[basarat]

You could use the "named" switch on classes and interfaces.

👍

[Steve-Fenton]

You could also use it to make a type nominal in a specific context, even if the type was not marked as nominal:

function getById(id: named CustomerId) {
    //...

[RyanCavanaugh]

You could also use it to make a type nominal in a specific context

What would that mean?

[Steve-Fenton]

When used as part of a type annotation, it would tell the compiler to compare types nominally, rather than structurally - so you could decide when it is important for the exact type, and when it isn't.

It would be equivalent to specifying it on the class or interface, but would allow you to create a "structural" interface that in your specific case is treated as "nominal".

Or, I have jumped the shark :) !

[RyanCavanaugh]

An example of an error (or non-error) would be nice. I can't figure out how you'd even use this thing

interface CustomerId { name: string }
interface OrderId { name: string }
function getById(id: named CustomerId) {
    //...
}
var x = {name: 'bob'};
getById(x); // Error, x is not the nominal 'named CustomerId' ?

function doubleNamed1(a: named CustomerId, b: named OrderId) {
    a = b; // Legal? Not legal?
}
function doubleNamed2(a: named CustomerId, b: named CustomerId) {
    a = b; // Legal? Not legal?
}
function namedAnon(x: named { name: string }) {
     // What does this even mean? How would I make a value compatible with 'x' ?
}

[Steve-Fenton]

This is why I'm not a language designer :)

I've shown in the example below that the keyword applies for the scope of the variable. If you make a parameter nominal, it is nominal for the whole function.

interface CustomerId { name: string }
interface OrderId { name: string }
function getById(id: named CustomerId) {
    //...
}
var x = {name: 'bob'};
getById(x); // Error, x is not the nominal 'named CustomerId'

function doubleNamed1(a: named CustomerId, b: named OrderId) {
    a = b; // Not legal, a is considered to be a nominal type
}
function doubleNamed2(a: named CustomerId, b: named CustomerId) {
    a = b; // Legal, a is compared nominally to b and they are the same type
}
function singleNamed1(a: named CustomerId, b: CustomerId) {
    a = b; // Legal, a is compared nominally to b and they are the same type
}
function namedAnon(x: named { name: string }) {
     // Compiler error - the "named" keyword can only be applied to interfaces and classes
}

[Steve-Fenton]

I admit that the notion of marking an item as nominal temporarily as per these recent examples may have been a little flippant - in the process of thinking through the implications of the feature I'm happy to accept it may be a terrible idea.

I'd hate for that to affect the much more straightforward idea marking a class or interface as nominal at the point it is defined.

[basarat]

Will need an inline creation syntax. Suggestion, a named assertion:

var x = <named CustomerId>{name: 'bob'};  // x is now named `CustomerId`
getById(x); // okay

Perhaps there can be a better one.

[ComFreek]

I wonder what the use cases for library developers are to not request nominal type checking via name.

Wouldn't you always be on the safe side if you use name by default? If the caller does have the right type, all is fine. If he doesn't, he must convert it (e.g. using the syntax @basarat suggested). If the conversion works, but doesn't work as expected, it's the user's fault and not the library developer's fault.

Maybe the whole problem is the duck typing system itself. But that's one problem TypeScript shouldn't solve, I suppose.

[sophiajt]

Not to sound like a sour puss, but being a structural type system is a fork in the road early on in how the type system works. We intentionally went structural to fit in better with JavaScript and then added layer upon layer of type system machinery on top of it that assumes things are structural. To pull up the floor boards and rethink that is a ton of work, and I'm not clear on how it adds enough value to pay for itself.

It's worth noting, too, the complexity it adds in terms of usability. Now people would always need to think about "is this type going to be used nominally or structurally?" Like Ryan shows, once you mix in patterns that are common in TypeScript the story gets murky.

It may have been mentioned already, but a good article for rules of thumb on new features is this one: http://blogs.msdn.com/b/ericgu/archive/2004/01/12/57985.aspx

The gist is that assume every new feature starts at -100 points and has to pay for itself in terms of added benefit. Something that causes a deep rethink of the type system is probably an order of magnitude worse. Not to say it's impossible. Rather, it's highly unlikely a feature could be worth so much.

[danquirk]

Agree with Jonathan here. I would have to see an extremely thorough proposal with some large code examples that prove this doesn't quickly become unmanageable. I have a hard time imagining how you could effectively use this modifier in a restricted set of circumstances without it leaking everywhere and ending up with you needing to use it on every type in your program (or giving up entirely on things like object literals). At that point you're talking about a different language that is basically incompatible with JavaScript.

Remember that nominal systems come with pain too and have patterns they don't represent as well. The trade off to enable those patterns with a structural system is the occasional overlap of structurally equal but conceptually different types.

[Steve-Fenton]

So the most common use case for this (that I can think of) is type-safe ids. Currently, you can create these in TypeScript by adding a private member to a class (or a crazy identifier on an interface, although that only reduces the chance, whereas the private member trick works as expected).

You have already made the decision that you want a nominal type when you create a type safe id class, because that is the purpose of such a class (and is the reason you aren't simply using number).

So my question is as follows, this code does what a lot of people want:

    class ExampleId {
        constructor(public value: number){}
        private notused: string;
    }

i.e. you cannot create another type that will satisfy this structure, because of the private member...

1. Would it be possible to formalise this behaviour with a keyword so the private member isn't needed?
2. Would it be possible to get this behaviour for interfaces?

The first of these two questions would probably cover 80% of the use cases. The second would allow similar cases and would be very useful from a .d.ts perspective.

This limits the feature to the creation of types that cannot be matched, which is already possible as described and for classes simply moves a "magic fix" into a more deliberate keyword.

I would be happy to write up something for this.

[danquirk]

Certainly feel free to try to write up something more complete that can be evaluated, although I will be honest and say the chances of us taking a change like seem quite slim to me.

Another data point to consider is that TypeScript classes had this behavior by default for some time (ie always behaved as a nominal type) and it was just very incongruous with the rest of the type system and ways in which object types were used. Obviously the ability to turn nominal on/off is quite different from always on but something to consider nonetheless. Also, as you note this pattern does allow some amount of nominal typing today, so it would be interesting to see if there are any codebases that have used this intermixing to a non-trivial degree (in a way that isn't just all nominal all the time).

[iislucas]

Note: lets not mix up the baby and bathwater here: the proposal in this
issue is not a nominal keyword for any type, but to support a specific
interface declaration of a nominal type. Nominal types are easy get right,
and pretty well understood to provide value; while a 'sticky' nominal type
annotation is tricky to do right. I'd suggest moving discussion of a
anywhere nominal type-tag to a different issue so as not to confuse the
two.

On Fri, Aug 1, 2014 at 4:37 PM, Dan Quirk [email protected] wrote:

Certainly feel free to try to write up something more complete that can be
evaluated, although I will be honest and say the chances of us taking a
change like seem quite slim to me.

Another data point to consider is that TypeScript classes had this
behavior by default for some time (ie always behaved as a nominal type) and
it was just very incongruous with the rest of the type system and ways in
which object types were used. Obviously the ability to turn nominal on/off
is quite different from always on but something to consider nonetheless.
Also, as you note this pattern does allow some amount of nominal typing
today, so it would be interesting to see if there are any codebases that
have used this intermixing to a non-trivial degree (in a way that isn't
just all nominal all the time).

—
Reply to this email directly or view it on GitHub
#202 (comment)
.

Lucas Dixon | Google Ideas

[sophiajt]

@iislucas - as mentioned earlier, structural and nominal are fundamental choices in the type system. Any time you rethink part of the fundamental design choices, you need to understand the full impact. Even if it seems to be isolated to a small set of scenarios.

The best way to full understand the impact is to have a more complete suggestion. I wouldn't confuse @danquirk's response as throwing the baby with the bathwater, but instead as the minimal amount of work any proposal would need that touches a fundamental design choice.

[iislucas]

I agree that a fully proposal is a good idea, and I'll do that. I worked a
long time in type-systems, so I'm pretty confident in my understanding of
whats involved here. But there are wildly different things being suggested.
So probably good to put each one into it's own discussion :)

On Fri, Aug 1, 2014 at 5:17 PM, Jonathan Turner [email protected]
wrote:

@iislucas https://github.com/iislucas - as mentioned earlier,
structural and nominal are fundamental choices in the type system. Any time
you rethink part of the fundamental design choices, you need to understand
the full impact. Even if it seems to be isolated to a small set of
scenarios.

The best way to full understand the impact is to have a more complete
suggestion. I wouldn't confuse @danquirk https://github.com/danquirk's
response as throwing the baby with the bathwater, but instead as the
minimal amount of work any proposal would need that touches a fundamental
design choice.

—
Reply to this email directly or view it on GitHub
#202 (comment)
.

Lucas Dixon | Google Ideas

[craigphicks]

This goes against the TypeScript principle that runtime equivalent types are equivalent. TypeScript promising to honor "nominals" would involve what worst case complexity in the CFA? Is it a type error to put them in flow superposition? Because once they are in superposition there is no way to separate them in runtime-space.

The exists multiple ways to distinguish at runtime already, as has been shown above.

Another is using Symbols, which JS provides specifically to be unique:

declare const symbolB : unique symbol; 
interface B {
    x: any;
    symbol: typeof symbolB;
};
declare const b:B;

const symbolA = Symbol("a");
interface A {
    x: any;
    symbol: typeof symbolA;
};
let a:A = b; // error
//  ~
// Type 'B' is not assignable to type 'A'.
//   Types of property 'symbol' are incompatible.
//     Type 'typeof symbolB' is not assignable to type 'typeof symbolA'.(2322)

const c = Math.random() ? a : b;
if (c.symbol===symbolB){
    c; // const c: B
}

I am against this proposal because promising the ability to distinguish types without runtime backing could be both extremely complex and have with extreme limitations in practice.

[ljharb]

@craigphicks for anything that's an object, the runtime definitely backs it - it'd only be a unique capability for primitives (which in practice, would likely just be strings or numbers).

[craigphicks]

@ljharb
Should this be an error?

const s = Math.random() ? s1 : s2;

If it is an error, then it is an error unlike any other type - currently this is never an error for any type.
If it is not an error, there is no way to separate the flow in runtime, so s is useless.

if (????) {
    s; // FooIndex
}
else {
    s; // BarIndex
}

What is the ???? to make the distinction possible?

[ljharb]

It's not useless just because it can't provide additional narrowing - it's just that some niche cases, like that one, won't benefit. However, this feature won't make it any worse.

[binki]

@ljharb Should this be an error?

const s = Math.random() ? s1 : s2;

If it is an error, then it is an error unlike any other type - currently this is never an error for any type. If it is not an error, there is no way to separate the flow in runtime, so s is useless.

Why would that be an error? Your s will have a union type of whatever types s1 and s2 are. If you pass s to a method which accepts the union of those types or any common base types, it'll pass.

if (????) {
    s; // FooIndex
}
else {
    s; // BarIndex
}

What is the ???? to make the distinction possible?

TypeScript already has custom type guards and support for instanceof which can be used to narrow types which use constructor functions (e.g., classes). The fact that type guards can't be supported for purely nominal types which aren't constructed types doesn't diminish the utility and expressiveness of nominal types, especially if they are types which shouldn't be dynamically tested in the first place.

[craigphicks]

Why would that be an error?

I am saying I think that should be an error, in order to warn users that the merging will be inseparable later. I am also saying that exactly highlights the limitations of nominal types. A nominal type can never be a discriminant.

TypeScript's power lies in it's ability to track flow superpositions and allow discriminants to separate those superpositions, and also that other bookkeeping is outside of its remit.

It's also think it is healthy that we disagree on this :) So I respect your opinion.

[ljharb]

@craigphicks it certainly can be a discriminant, often! it just can't always be one.

[binki]

Why would that be an error?

I am saying I think that should be an error, in order to warn users that the merging will be inseparable later. I am also saying that exactly highlights the limitations of nominal types. A nominal type can never be a discriminant.

It shouldn’t be an error because it is a valid thing to do. Especially if s1 and s2 have a common base nominal type. TypeScript already supports union types, so there is a way for it to track this type information. The request for nominal types is not a request for a revolution of how TypeScript already works. Conflating the request makes it less simple, loses sight of the actual feature being requested, and reduces the chance of this feature being considered.

TypeScript's power lies in it's ability to track flow superpositions and allow discriminants to separate those superpositions, and also that other bookkeeping is outside of its remit.

I don’t know what TypeScript’s strengths, etc. are. To me, it allows me to get static type checking in a more explicit and community-supported way than Flow without significantly adding overhead (unless you’re targeting a version of JavaScript which doesn’t have built-in async/await support). Static type checking is useful because it allows you to instruct the compiler about what is illegal. Nominal types are more useful than shapes because nominal types allow the compiler to enforce semantics instead of merely preventing specific runtime errors. Since TypeScript is more explicit in the definition of types than Flow, that means that its style of type tracking lends itself toward the definition of nominal types. Since TypeScript is a widely accepted standard and it already has the infrastructure for tracking types, it is discouraging to see that there is no plan to enable this programming technique.

[PonchoPowers]

Since almost 10 years has passed from when the suggestion was first made, it doesn't look as if this is ever going to be supported. Anyone wanting to achieve this without vscode bringing up a prompt for the nominal property when typing, you can include a space at the start of the property name, like in the following example, because hacks are clearly the better choice :-s

interface FirstNameInterface {
  ' FirstNameInterface': never;
}

interface LastNameInterface {
  ' LastNameInterface': never;
}

class FirstName implements FirstNameInterface {
  ' FirstNameInterface': never;
}

class LastName implements LastNameInterface {
  ' LastNameInterface': never;
}

function printName(first: FirstNameInterface, last: LastNameInterface) {}

const first = new FirstName();
const last = new LastName();

printName(first, last);
// OUTPUT: Emma Johnson

// Compiler error!
printName(last, first);

[nathan-chappell]

I got sent here from #42534, about a type related issue that isn't caught by typescript (assigning a Uint8Array to an ArrayBuffer). Quite frankly, the TS guys had me at we do structural subtyping and don't support nominal subtyping, I mean there you go. BUT, if the typing system leads to a small number of incompatibilities with the existing language runtime, then could the TS compiler at least recognize these? I guess it's complicated by the web/node/etc differences, but I would be happy if TS could recognize these known issues that are baked-in and give me a heads up...

[craigphicks]

@nathan-chappell - In 5.4.5 the second line is an compile error (also a runtime error)

new DataView(new ArrayBuffer(2))
new DataView(new Uint8Array([1,2])) // Error

[nathan-chappell]

@craigphicks this is the issue:

const arrayBuffer: ArrayBuffer = new Uint8Array()
const dataView = new DataView(arrayBuffer)

[craigphicks]

@nathan-chappell I see.

I guess the js run time error is caused by js using a test equivalent to instanceof ArrayBuffer, that uses the constructor associated with passed object inside the constructor for DataView

However, in the TS library for JS objects, type representing instances of constructed objects do not have associations back to the constructors.

For example ArrayBuffer is declared a variable of type ArrayBufferConstructor, but the type returned by new ArrayBuffer() doesn't have a reference to the constructor. It's not in the type on <object>.prototype.constructor.

Similarly for Uint8Array.

That's a design choice, and behind it is the presumption that the constructor doesn't matter - all that matters is the object structure.

Perhaps it could be fixed by making the prototype.constructor public on the interface of objects for which assignability should require the same constructor.

I think that's off topic for "non-structural (nominal) type matching" - which is the subject of this thread, because it is structural.

[nathan-chappell]

@craigphicks Well I already agreed with the design choice. I haven't read all 600 posts here, but the point is that the structural subtyping is incorrect in this case due to unexposed details, and nominal subtyping would solve the issue. Here is a real case where this functionality is needed to avoid runtime errors that could ostensibly be found by typescript without overhauling the entire philosophy - that is, gradual nominal types, initially only where it is required for correctness.

This isn't appropriate for this thread?

[snarbies]

Tying an interface to a specific class sounds to me like the definition of nominal typing. Branding, or any moral equivalent (e.g. prototype.constructor), is an attempt to emulate nominal typing in a structural system. And in general the prototype.constructor solution would fail if two types had structurally equivalent constructors. The situation here is genuinely two nominally distinct types.

[craigphicks]

@nathan-chappell @snarbies

Nominal typing for object types is currently available to users on a case-by-case using using symbols.

const symbol1 = Symbol("1");
const symbol2 = Symbol("2");
interface I1 {
    symbol: typeof symbol1
}
interface I2 {
    symbol: typeof symbol2
}
declare function f1(x:I1): void;
f1(0 as any as I1); // No Error
f1(0 as any as I2); // Error

Using symbols also has the advantage that it corresponds to a runtime usable discriminant.

(Note: Above I wrote "making the prototype.constructor public" but that was wrong because obviously that would only share the type of the constructor).

Typescript could allow a unique constructor representative thing similar in behavior to a unique symbol to be optionally made public and automatically used for assignability checking when it is present.

That would be helpful in a number of cases - e.g.

1. A class with an otherwise empty public interface which currently has no type checking at all. It wouldn't be a lie because instanceof does actually expose that uniqueness.
2. It would allow TS (or some other library) to write something like the following overload definition for the standard JS-array function Array.filter,

type Array {
  ...
  filter<T,R>(x:T, f: Boolean, ...): Exclude<T, 0|-0|typeof NaN|null|undefined|false|"">[];
  filter<T>(x:T, f: (x:T, f: ...)=>any, ...): T[];
  ...
}

That can't be done presently because anything Boolean-like would pass the assignment test but it could be a different class with different behavior.

[snarbies]

I think I might have misunderstood part of your original comment. I thought you were suggesting that the distinction between ArrayBuffer and UInt8Array was structural and thus off-topic, but perhaps you meant your prototype.constructor idea was off-topic. If that's the case, sorry for misunderstanding.

[craigphicks]

@snarbies - I was actually interpreting "non-structural nominal typing" as applying only to TypeScript functionality of discriminating types for which there is no runtime way to distinguish between them (That may be an incorrect assumption about this thread and if so I apologize). That's certainly a topic in it's own right. In contrast this ArrayBuffer vs. UInt8Array problem is about a case where runtime can discriminate, but TypeScript cannot. Even if overlaps with this thread, it has a component worth of being in another thread.

[craigphicks]

Thanks @nathan-chappell and @snarbies for your thought provoking feedback. I've submitted a proposal #58181 as an attempt to resolve the problem.

[nathan-chappell]

@craigphicks Great, thanks, cheers.