As operator

[Ryan Cavanaugh (RyanCavanaugh)]

Implements as operator as suggested in #296.

[Mohamed Hegazy (mhegazy)]

why do you need this token?

[Anders Hejlsberg (ahejlsberg)]

Don't think we need to store the as token.

[Daniel Rosenwasser (DanielRosenwasser)]

Can we have a few tests for templates in tests/cases/.../es6/templates/?

varx=`${123+456asnumber}`;vary=`leading ${123+456asnumber}`;vary=`${123+456asnumber} trailing`;

var x = `Hello ${123} World` as string;
var y = `Hello` as string;
var z = 1 + `${1} end of string` as string;

declarefunctiontag(...x: any[]): any;varx=tag`Hello ${123} World`asstring;vary=tag`Hello`asstring;

[Yui (yuit)]

Should we add formating rule for as?
For example:

varx=42asstring;

will become

varx=42asstring;

[Yui (yuit)]

Could we add some tests:

vara=20;varb=aasstring;varas="hello";varas1=asasstring;

[Tingan Ho (tinganho)]

I'm just wondering if we can support inferred type assertions and if it is a good idea?

Instead of:

(foo as Foo).(bar as Bar).text

We could just use:

foo.bar.text

And it will infer the type by looking at the last property.

[Daniel Rosenwasser (DanielRosenwasser)]

Should we add formating rule for as?

If by formatting rule, you mean a restriction, yes (good catch!), but not related to the example you just gave (nowhere else in the language do we differentiate whitespace on the same line). Consider the following:

classFoo{}declarefunctionas(...args: any[]);// Example 1varx=10as`Hello world`// Example 2vary=20as(Foo);

Example 1 is not as much of a problem; you can't use a template string as a type.

Example 2 suffers from potentially the same problem as #2995. as would ordinarily be a function call with a constructor function, but here it is a type assertion on 20 to Foo.

[Daniel Rosenwasser (DanielRosenwasser)]

Yui (@yuit) Ah, by formatting rule, you meant in the LS - still, glad we caught this.

[Yui (yuit)]

Daniel Rosenwasser (@DanielRosenwasser) yes, I mean from LS side similar to:

functionfoo(){}

become

functionfoo(){}

Though you example will be a good one to add as well.

[Daniel Rosenwasser (DanielRosenwasser)]

else on the next line.

[Ryan Cavanaugh (RyanCavanaugh)]

Any other feedback?

[Cyrus Najmabadi (CyrusNajmabadi)]

just add a comment for this case.

[Daniel Rosenwasser (DanielRosenwasser)]

else on the next line

[Daniel Rosenwasser (DanielRosenwasser)]

You're currently not contextually typing the left-hand side of the as operator. So if you take

varx=(v=>v)as(x: number)=>number

v gets typed as any right now. This means that

varx=(v=>v)as(x: number)=>string

currently typechecks without a problem even though

varx=<(x: number)=>string>(v=>v)

gives an error.

[Daniel Rosenwasser (DanielRosenwasser)]

Can we also have the following tests to demonstrate left-associativity of as?

_{asOperatorAssociativity01.ts}

varx=10asnumberasanyasstring// should be okay

_{asOperatorAssociativity02.ts}

vary=10asstringasnumber;// should error

[Ryan Cavanaugh (RyanCavanaugh)]

Anything else?

[Daniel Rosenwasser (DanielRosenwasser)]

Are we leaving the services layer to a second pass? I can think of at least:

• Formatting tests
• Does as get occurrence highlighting to point out type assertion locations? (kind of useful; it's the point of static_cast etc. in C++).
• Completion list tests for arrow functions:

classC<T>{constructor(){// C, T, and U should show up below.letf=<U>(x: any)=>xas/**/

typeA=any;namespacen{typeB=any;// A, B, T, and n should show up below.letf=<T>(x: any)=>xas/**/

• Completion list tests to ensure that you never have a new identifier location after an as.

[Daniel Rosenwasser (DanielRosenwasser)]

I am working on a change such that keywords like interface must be followed by an identifier on the same line to be considered the start of an interface declaration.

But as is only a type assertion if it follows an identifier on the same line. So there's an ambiguity.

It seems like the appropriate thing to do is to treat it as an declaration named as.

You'll have to account for this with some tests like:

interfaceas{}

interfaceas{}

interfaceas({})

namespaceas{}

declareas{}

typeas=number;

[Jason Freeman (JsonFreeman)]

Can you just check scanner.hasPrecedingLineBreak instead? I don't really like canParseSemicolon that much.

[Mohamed Hegazy (mhegazy)]

Ryan Cavanaugh (@RyanCavanaugh) is this ready to go in?

[Ryan Cavanaugh (RyanCavanaugh)]

I'm merging this up with the JSX work, which should have a PR in a day or so

[Mohamed Hegazy (mhegazy)]

closing in favor of #3564