Stricter type aliases

[d180cf]

Let's say we have an alias for number:

/** bits 0..3 = x, bits 4..7 = y, bit 31 = always 1*/
type coords = number;
/** x = 0, y = 0 */
const zero: coords = 0;

The zero variable, despite being of type coords, will act everywhere as though it's a plain number: the language service will say that it's a number, the compiler will treat it as a plain number and so on. However the coords type is not just a number because it has some internal structure and because not every value of type number is a value of type coords (in other words, the set of values in coords is smaller than the set of values in number).

It would be nice if the language service displayed the proper type name in such cases and if the compiler put some constraints on operations with such custom types, e.g. const zero: coords = 0 should error because 0 is of type number which may be (the compiler doesn't know) wider than coords.

[DanielRosenwasser]

#364 is definitely related. So is #202 to some extent.

[DanielRosenwasser]

As for the language service displaying the declared name, it's probably better not to do that so that users understand what they're actually dealing with. It would be inappropriate to give users the impression that the language is doing what this proposal asks for with respect to the type keyword.

On the other hand, for a different declaration that does something close to what Haskell's newtype does, we would probably do that.

[GoToLoop]

As a very poor workaround I'm using empty enums. For example:

declare const enum coord {}
declare const enum size {}

type xy = [coord, coord]
type wh = [size, size]

mouseX: coord
mouseY: coord

width:  size
height: size

ellipse(x: coord, y: coord, w: size, h: size): this

[mhegazy]

also related #4895

[mhegazy]

looks like a dupe of #2477

[d180cf]

@GoToLoop, that's actually a decent workaround. Thanks!