Back type assertion

[tinganho]

Instead of writing:

foo/*1*/
// and then go back with the cursor
/*1*/foo
// and then write the type assertion
(<Foo>foo).bar/*1*/
// and then go back with the cursor
/*1*/(<Foo>foo).bar
// and then write the type assertion
(<Bar>(<Foo>foo).bar).text/*1*/

We could just write it without going back-and-forth with the cursor:

foo<Foo>.bar<Bar>.text

It is also easier to map the type to each property accessor.

[duanyao]

This is exactly the major problem of current type assertion syntax, and I also feel painful when moving the caret.

However, the syntax you suggested may conflict with generics sometimes, e.g.:

type Foo = (a: number, b: number)=> number;
var foo = function foo<T>(v: number) { return v * v; };
(<Foo>foo)(1, 3); // OK
foo<Foo>(1, 3); // what does this mean?

I suggested as operator with same precedence as . (#296 (comment)) , so your example can be:

foo as Foo .bar as Bar .text

and my example can be

foo as Foo (1, 3); 

However, @CyrusNajmabadi doesn't like the high precedence of as, because if you have a type in a namespace, say mylib.Foo, you have to write foo as (mylib.Foo), not foo as mylib.Foo. But I don't think this is a big problem.

[tinganho]

foo<Foo>(1, 3); // what does this mean?

Does it interfere or interplay? You are passing a type arg to a generic. Would it be something difference than to type assert it?

[duanyao]

It depends on the precedence of <Foo>, and foo<Foo>(1, 3) could also mean (foo<Foo>)(1, 3).

[tinganho]

type Foo = (a: number, b: number)=> number;
var foo = function foo(v: number) { return v * v; };
(foo)(1, 3); // OK
foo(1, 3); // what does this mean?

I think I see your point now. I assumed passing in a type on a generic was interchangeable with type asserting it. But your first example clarifies that they aren't.

Why is type asserting functions useful? Isn't it more useful to write a new function instead? Then we could just ban type assertions in functions and regard them as generic calls?

I like the bracket notation instead of as because foo as Foo .bar as Bar .text looks very bloated.

[tinganho]

I also noticed that it interferes with generic classes as well. My proposal might not be that good. I will keep the issue open for discussion. Because I still see it as a problem to go back-and-fort with the cursor.

[tinganho]

How about just?

foo:Foo.bar:Bar.text
f:Foo(1, 2)

It's very consistent with the current type definition syntax.

[duanyao]

: has been used for quite a few different purposes.
{ foo : (bar : Bar) } and { (bar : Bar) } and foo = expr ? (bar : Bar) : null; etc. look not very pleasant.

It seems that TS guys don't like the idea of a type assertion operator with equal or higher precedence than ., so the parentheses are still needed. Hope IDEs can autocomplete parentheses around type assertions, sigh.

[RyanCavanaugh]

Ref #296

[duanyao]

@RyanCavanaugh 👍

[tinganho]

👍