This project is read-only.

Subtyping primitive types

Topics: General
Jun 21, 2013 at 7:59 AM

I have recently been trying to subtype primitives and wasn't successful at it. I was wondering if that was possible at all and if not, whether that could be added to the language.

The use case is to be able to put constraints when using primitive types. For instance, requestAnimationFrame has as argument a callback with a number (HighResolutionTimeStamp) passed as argument when called. returns a number too. They may look like comparable, but one is in milliseconds since Jan 1st 1970 and the other milliseconds since "navigationStart", so the difference is meaningless. It'd be interesting if it was possible in TypeScript to express that and that the compiler issues a warning or an error when trying to substract both.

In physics calculation, it would enable to represent values as numbers in the JS runtime, but have type checks to prevent adding seconds to meters, etc.

Also, sometimes, strings are formatted in a certain way and have implicit types. And these types have relationship. Most recently, in a Firefox Jetpack addon, I came across this case where when you use the simple-pref module [1], you manipulate identifiers and under the hood, there is a convention using string concatenation to map your identifier to an "internal" preference identifier. It'd be nice if there was a way to express this difference in a way that allows to keep manipulating strings at runtime but runs through the type checker beforehand too.



Jun 21, 2013 at 2:41 PM
Or just right now, I'm playing with Google App Script and it's quite annoying to have to play between spreadsheet ranges [1] and value array coordinates [2] as there is a +1/-1 shift to operate between one and the other. Having types to check which I'm currently manipulating and not mess up with off-by-ones would be nice.

I think there are thousands of implicit primitive subtyping happening all the time.

Jun 24, 2013 at 9:44 PM
Yeah, as you've noticed subtyping of primitives is not currently supported. The use cases you mention are indeed compelling in almost all programming languages, the majority of which don't have nice support for differentiating between different 'types' of numbers/floats/etc (F# has a feature called Units of Measure which is great for this). It is certainly worth considering somewhere down the line. Currently we only have enums as a number-like type which would give you some static checking when they're mixed incorrectly. For your last example using strings it may be the case that our new Overload On Constants feature helps somewhat. That said, you should file a Codeplex issue for this feature so others can vote on it if they also like the idea and we can add it to our (long) list of suggestions for future versions.