When possible, reuse existing syntax from typescript or flow, if applicable

[cybrown]

It seems like the javascript and strong typing community are using an emerging standard for type annotations (typescript, flow, babel... maybe sound script ?)

As of today, a big part of rtype syntax looks like those annotations, but there are small differences.

It would be nice to have the same syntax for the shared features, to increase the chance of using multiple tools, each of them for there usage, with the minimum requirements.

Some examples of differences:

• Union types: Spec Preview: Union types microsoft/TypeScript#805 (double pipe instead of simple pipe)
• Type intersection: Intersection types microsoft/TypeScript#1256
• Using Function instead of func
• Function signatures uses the arrow notation for the result type

[ericelliott]

Thanks for your input!

The reason I had in mind for the syntax differences was that there are a LOT more developers familiar with JS syntax than TypeScript syntax, and I wanted to err on the side of familiarity for the majority of developers.

That said, you are right that the community seems to be converging on a recognizable set of standards for type support, and that set has the restriction of being embedded in JavaScript, so if we go our own way, there will be two completely different syntax sets for types, and that's probably even more confusing to JS devs.

That said, starting right now, a core design goal will be to pave the cowpaths and try to be as familiar as possible to users who are familiar with other type systems in the JS ecosystem... TypeScript being the standard bearer.

That said, I am far from a TypeScript expert, because if it suited my needs, I wouldn't be working on this project in the first place. I'd just use TypeScript, instead. So I'm going to need some help from the TypeScript community to stay on track.

• I was aware that our union types were different from TS.
• I was unaware that TS supports intersection types. So far I haven't even tried to express intersection types. My strategy documenting my own code was to default to unrestrictive types such as the generic object for values that don't have easily predictable unions -- specifically because I have never seen a good implementation of intersection types that correctly predicts the object shape in every scenario possible in JS.

How does the TS intersection work? For instance, how would you model the deep property merge from lodash/object/merge? Do the intersection types allow the flexibility required? The topic of intersection types my need it's own discussion thread to get right, and it may need to diverge from the TypeScript implementation -- or perhaps it's better to advise people to use generic types instead of attempting a strong model for intersections.

Function signatures uses the arrow notation for the result type

Which function signatures are those? AFAIK, both TypeScript and Rtype use (): returnType -- an idea I blatantly stole from TS after using () => in my documentation for the past year+, specifically for the purpose of being familiar to TS users.

[ericelliott]

The safe changes are merged. More discussion is needed on intersection types. AFAIK, we are compatible with TypeScript return type notation already. Closing for now. Feel free to open more tickets for specific problems.

Thanks a lot. =)

[cybrown]

About function return type signatures, in typescript, a colon is used in class or interface methods, but function expression are expressed with a fat arrow.

In this example, both types are equivalent:
http://bit.ly/1OrIU7F

This might be specific to typescript, and as I said before, it would be nice to have the same syntax for things that are already the same in different tools.

[ericelliott]

About function return type signatures, in typescript, a colon is used in class or interface methods, but function expression are expressed with a fat arrow.

Why is there a difference?

[cybrown]

I don't know, btw it's the same in scala

[ericelliott]

I'm not very familiar with TypeScript, yet. I thought I was following their lead, but I have trouble understanding how TS disambiguates between return type notation and creating a new function when you're annotating a function inline.

Can you explain how that disambiguation works?

[cybrown]

I'm just a TypeScript user, I do not know the internals, sorry.

[mindplay-dk]

I dislike the proposed convention of lowercase type aliases - the argument that you won't need to scan backwards through the code looking for a type declaration is moot, since, with static typing, I'd more likely just hover the mouse over the name to see what's what.

Also, the Typescript/C# convention of using a leading capital T (or a single capital letter) to me is actually less visually ambiguous, as the lowercase letter resembles a var name.

[ericelliott]

@mindplay-dk If you mean type variables, we're intentionally deviating from TypeScript here in order to better support higher order functions and generics.

We're going to add support for Haskell style type constructors, which means we can do things like this:

Functor F ~> map(a => b) => F(a) => F(b)

Where F is a type constructor, F(a) is a new type representing a functor of a, and F(b) is a type representing a Functor of b.

It's difficult/impossible to represent that readably in TypeScript, which is the primary reason for this deviation.

We haven't documented that in the official spec yet because I'm still experimenting with the new syntax.

The squiggly arrow is basically saying F is a member of the Functor type class in the map signature declaration. You can read it, F is a member of Functor in ...

[ericelliott]

BTW, we've had lots of discussions RE: how TypeScript/Java et al... handle generics and to what extent we should or should not support it. Haskell's solution is simple and elegant by way of comparison.