Add “Composing types”

[tomek-he-him]

Fixes #9.

This is also my contribution to the discussion on interface collisions. I think it should be valid to override more generic types like String with more specific ones like /^[a-z]+$/.

[ericelliott]

How about "This is an rtype error: Interface type collision:"

[tomek-he-him]

Yeah, for the user it would be perfect if we detected type collisions statically. But such a promise might be risky on our side as there’s no obvious way to detect some conflicts. Like a: /^[A-Z]+$/ and a: /^[a-z]+$/ or n: (number) => number < 0 vs n: (number) => number > 10.

[ericelliott]

I think mismatched literals are conflicts by definition, don't you? If they're the same type, they should be the same literal, shouldn't they?

We shouldn't try to infer compatible types for literal definitions. Right?

[tomek-he-him]

Yeah, that sounds reasonable and definitely makes things simpler. Fair enough. I’ll push an update ASAP.

(Though /^\w/ and /^[abc]/ are compatible. I can think of lots of other examples.)

[ericelliott]

Great work so far!

[ericelliott]

(Though /^\w/ and /^[abc]/ are compatible. I can think of lots of other examples.)

So can I, but is there an easy way to detect compatible types like this safely and automatically, for all compatible cases?

Also note, this is compatible one way, meaning all matches of /^[abc]/ will also match /^\w/, but the reverse is not true.

[tomek-he-him]

So can I, but is there an easy way to detect compatible types like this safely and automatically, for all compatible cases?

Nope, that’s what I meant too. Your idea is very good!

[tomek-he-him]

Does that sound better?

[tomek-he-him]

Also, I’m wondering about one more implication of this syntax. I have the following in a project:

interface Integer
  (number) => (
    typeof number === 'number' &&
    number === parseInt(number, 10)
  );

interface PositiveInteger
  (number) => (
    typeof number === 'number' &&
    number === parseInt(number, 10) &&
    number > 0
  );

Since we can merge types by spreading them out within an interface block, should this mean the same?

interface Integer
  (number) => (
    typeof number === 'number' &&
    number === parseInt(number, 10)
  );

interface Positive
  (number) => (
    typeof number === 'number' &&
    number > 0
  );

interface PositiveInteger { ...Integer, ...Positive }

[ericelliott]

this mean the same?

interface Integer
  (number) => (
    typeof number === 'number' &&
    number === parseInt(number, 10)
  );

interface Positive
  (number) => (
    typeof number === 'number' &&
    number > 0
  );

interface PositiveInteger { ...Integer, ...Positive }

Yeah, I like this! =)

[ericelliott]

Are we adding an example like the one above?

[tomek-he-him]

Hi @ericelliott, I’ve been busy for a while – sorry.

One thing bothers me though. In the same section we say

To make sure we can run a static type check for you, we don’t allow merging two different literals. So this would result in a compile error:

interface Human {
  name: /^(.* )?[A-Z][a-z]+$/,
}

// Invalid!
interface Professor {
  ...Human,
  name: /^prof\. \w+$/,
}

Merging predicate literals like Integer and Positive is in fact the same thing. It can’t be statically checked.

How about making the static check opt-out? Some things (like merging literals) could just trigger a “you’re on your own” warning.

[ericelliott]

I want to see this in the spec. I think we can sidestep the issue for now by making it an error if you try to merge literals.

[tomek-he-him]

Alright! I don’t think there were any other open issues. Should I merge?

[ericelliott]

Obviously, resolve the conflicts first.. =)