Support nominal type aliases

[rpominov]

Sometimes I have two types, and both of them are numbers, for instance, but at the same time have absolutely different meaning. Can I express this in Flow? I tried type aliases, but they are simply interpreted as the types they alias, so this code type checks:

/* @flow */

type UserId = number;
type NumberOfFollowers = number;

function hasLotOfFollowers(followers: NumberOfFollowers): boolean {
  return followers > 1000;
}

var userId: UserId = 100;

// Expecting error here
hasLotOfFollowers(userId);

$ flow
No errors!

[samwgoldman]

Flow's type system is structural by design and what you are proposing would behave more like a nominal type system. I don't believe the existing behavior of type aliases will change, but we might consider supporting a way to make nominal types, because this absolutely would provide type safety.

However, there are a few details to sort out. Assume we had something like the following syntax:

type UserId = $Nominal<number>

How would you create an inhabitant of the UserId type? Would number be able to flow into a UserId?

I am reminded of Haskell's newtype wrappers. You need to "construct" the value in the newtype and "unwrap" the newtype to get at the inner value, but the compiler is able to erase that at compile time, making it a zero-cost abstraction.

Ignoring the compiler support for unwrapping for a moment, we currently support something like this:

/* @flow */

class UserID {
  id: number;
  constructor(id: number) {
    this.id = id;
  }
  get() {
    return this.id;
  }
}

class AdminID {
  id: number;
  constructor(id: number) {
    this.id = id;
  }
  get() {
    return this.id
  }
}

var userID: UserID = new AdminID(1);
var adminID: AdminID = new UserID(2);

test.js|23 col 26 error|  AdminID
|| This type is incompatible with
test.js|3 col 7 error|  UserID
|| 
test.js|24 col 28 error|  UserID
|| This type is incompatible with
test.js|13 col 7 error|  AdminID

That is to say, classes are nominal in Flow.

I think it would be VERY interesting to support a newtype semantics for classes like this, which wrap a single value, but that would involve rewriting javascript, which flow doesn't actually do—babel does it for us.

Ultimately, I don't have an answer here. Can you write your code to use a class wrapper for these values?

[rpominov]

Thank you for the detailed answer! It would be indeed very interesting if Flow would support something like nominal types. This would provide support for extra type safety for those, who want it, but I understand now that the cost will be to annotate every creation of an inhabitant.

I was considering using classes as wrappers, but in my particular case it would be an overkill. Anyway this technique might be useful in some cases.

Thanks!

[avikchaudhuri]

Yeah, thanks @samwgoldman for the detailed answer. We have thought about newtype off and on, and don't quite know how to do it other than inventing wrapper syntax that gets stripped off.

So something like

newtype userid = number // or type userid = $Nominal<number> as you have above

that satisfies:

var u: userid = userid(0);
(u: number); // OK, we can explicitly require unwrapping to be stricter, but this should suffice

Basically this design allows userid to be used wherever numbers can, e.g. in arithmetic operations. But not all numbers are userids. Also, not all userids are ages, if age is another newtype: the wrapping has to be explicit.

Want to work on something like this?

[samwgoldman]

Stripping off whatever wrapper syntax is the big hurdle here, IMHO. Adding functionality to flow that transforms source files makes me hesitate to volunteer for this one.

Maybe we could leverage the casting syntax both ways?

newtype userid = number; // agree this is good "official" syntax, but I would start with $Nominal
var u = (0 : userid);
u * 10; // error
(u : number) * 10; // ok

Then, instead of using the vanilla flow logic for type casts, run something with special cases for type aliases before falling back to vanilla flow.

[gregwebs]

@samwgoldman allowing casting for this anywhere is problematic

• you are now taking any newtype of a number in your multiplication function
• there is no restriction on where wrapping and unwrapping can occur

In Haskell one controls all this at the definition site, in particular whether a constructor is exported and/or a function for unwrapping is exported. By convention the unwrapping function usually has an un prefix, so unUserId.

newtype UserId = UserId { unUserId :: Int } deriving (Read, Show, Eq, Ord, Num)

If I only want to provide the ability to unwrap, but not to construct, I just export unUserId.
Now by not exporting the newtype constructor I can guarantee that the rest of my functions are properly working with minutes.

So to use casting as is, one needs the ability to do fine-grained exports. However, the other problem is the ambiguity of over-loading casting. It is no longer clear whether the user wants to cast or deal with a newtype. So you might consider adding a new syntax such as (0 : number -> userid) and (u : userid -> number). Note that I am not using the fat arrow which is already used for function types.

[samwgoldman]

@gregwebs Good insight.

Our constraint is that we can only play with the type language, not the runtime language. Seems like you're keyed into that, based on the syntax you recommended. I think that syntax could work (although I worry about confusion when a user types -> isntead of =>, as I sometimes do).

Regardless, your point about newtypes being one-to-one is well taken.

[raould]

+1 to this overall request. This is one of the first things I look for in a type system.

[raould]

To contribute to the bike shed UX discussion of the arrow, I propose ">". Or you can consider avoiding an arrow: just ""; or "castto"; or "x from y"; or reversing the order so the arrow points backwards to be really even more distinguished from "=>", are other brainstorms. :-)

[latos]

You can achieve the desired effect with this trick (not sure if this is mentioned elsewhere?):

// @flow


type UserId = { _Type_UserId_: void }  // dummy field unlikely to happen accidentally in code


function UNSAFE_CAST(x:any) { return x; }
var NewUserId : (val:string)=>UserId = UNSAFE_CAST;
var FromUserId : (userId:UserId)=>string = UNSAFE_CAST;


var userId : UserId = NewUserId('u1');

// At runtime, just a naked string
console.log("Runtime value:", userId, "Runtime type:", typeof userId);

// This line would fail the flow type check
// var str : string = userId;

var str : string = FromUserId(userId);

This is pretty close to a zero-cost abstraction, except for calls to the no-op identity functions for "boxing" and "unboxing". However, one option here (if using something like webpack) could be to write a loader to strip out these conversion functions.

Or one could just use the any type to box/unbox for free... e.g.

var userId2 : UserId = ('u1':any);
var str : string = (userId:any);

The second line could be made a little less distasteful

// assert that it was a UserId before unsafely casting it to string
var str : string = ((userId:UserId):any);

[vkurchatkin]

@latos using classes is better for this purpose, because they are actually nominally typed

[gcanti]

@latos I agree with @vkurchatkin since you must wrap / unwrap anyway.

Your trick might be used to define custom refinements though

type Integer = number & { __refinement_Integer: void };

function integer(n: number): ?Integer {
  return n % 1 === 0 ? ((n: any): Integer) : null
}

function foo(n: number) {
  return n.toFixed(2)
}
function bar(n: Integer) {
  return n.toFixed(2) // <= no need to unwrap, `Integer`s are `number`s
}

integer(1.1) // => null
const i = integer(1)

foo(1)
// bar(1) // error

if (typeof i === 'number') {
  foo(i) // <= again, `Integer`s are `number`s
  bar(i)
}