Cast to Any

[laktak]

TS Handbook:

The 'any' type is a powerful way to work with existing JavaScript, allowing you to gradually opt-in and opt-out of type-checking during compilation.

Though when I want to opt-out I often have to cast using <any> which isn't very readable (e.g. (<any>window).myProperty).

Is there a better way to opt-out of type checking?

[RyanCavanaugh]

window["myProperty"]

[laktak]

window["myProperty"]

Thanks but I don't think this shows the intention like the cast to any does. Also it produces different js.

Would it be possible to add an any-operator, like # or something similar? e.g. #window.myProperty

[RyanCavanaugh]

I don't think we're going to add extra syntax for turning off typechecking -- there's already a lot of options.

Are you aware you can augment existing types?

interface Window {
  myProperty: any;
}

[laktak]

I don't think we're going to add extra syntax for turning off typechecking -- there's already a lot of options.

What else is there except for the two listed above?

Are you aware you can augment existing types?

Yes but we are trying to avoid that.

While definitions (like those on https://github.com/borisyankov/DefinitelyTyped) look good at first they often (usually?) go out of sync with reality really quickly.

TypeScript works really well for our own projects but for 3rd party libraries it hurts more than it helps.

[kitsonk]

Yes but we are trying to avoid that.

Why?

I don't see how #window.myProperty is any different from (<any> window).myProperty either. You said you were trying to solve readability issues. How is that any more readable?

[RyanCavanaugh]

There's <any>, there will soon be an as operator (#3201), the string indexing notation suggested, updating the .d.ts file, augmenting the interface yourself, or assigning into a variable of type any.

If a .d.ts file is out of date with regard to the library, the answer is to fix it. Be the pull request you want to see in the world.

[laktak]

@kitsonk

Yes but we are trying to avoid that.

Why?

Like I said, 3rd party definitions are almost always out of sync. Having the compiler give you wrong error messages is frustrating.

I like Typescript because it allows me to use types where they provide value and opt-out/use pure JS when I don't need them.

[laktak]

@RyanCavanaugh thank you for the info.

Will it allow x as any.property or do I need (x as any).property?

If a .d.ts file is out of date with regard to the library, the answer is to fix it. Be the pull request you want to see in the world.

When TS catches on and the d.ts is maintained by the library then that's great. Otherwise it's not worth it IMO.

[RyanCavanaugh]

The syntax would be (x as any).property.

DefinitelyTyped gets over a dozen commits per day; I'm honestly surprised you're running into this with any frequency. Which libraries are you using, out of curiosity?

[laktak]

The syntax would be (x as any).property.

As the implementation appears to be unfinished, would it be possible to increase the precedence for the as operator so that the parentheses are optional?

DefinitelyTyped gets over a dozen commits per day; I'm honestly surprised you're running into this with any frequency. Which libraries are you using, out of curiosity?

I don't remember all of them but there were issues with jquery, lodash or underscore, pixie, bluebird, es6-shim and a few others.

[RyanCavanaugh]

The logical interpretation of x as Something.Foo is that the type name is Something.Foo. I don't know of any language that puts dot as lower-precedence operation than a binary operator.

[duanyao]

@RyanCavanaugh TS heavily relies on type assertion when writing DOM-related code, this is also rarely the case in other languages. In my experiences, type assertion is a major produtivity-reduction factor of TS, so I think high-precedence type assertion can justify itself to some extend.

On the other hand, we can also reduce type assertions by improving the library(lib.d.ts) instead of the language, as I suggested in #424 (comment) , and discussed in #3220 and #3263 . I really hope TS team to take this problem seriously.

[kitsonk]

TS heavily relies on type assertion when writing DOM-related code, this is also rarely the case in other languages. In my experiences, type assertion is a major produtivity-reduction factor of TS, so I think high-precedence type assertion can justify itself to some extend.

Actually, I would argue totally differently. The strong type assertion, aligned to what the standards are, is one of the biggest productivity boosters and sort of the whole purpose of TypeScript. I am just an outsider, but to be honest, @duanyao none of your arguments make logical sense. Now you are inserting yourself in random issues which have nothing to do with the DOM (the individual was feeling that 3rd party typings were not being updated enough in which he wanted an "easier" way to break strong typing, though clearly his definition of easy is quite what most other people would consider easy).

If you don't like TypeScript, then maybe you shouldn't use TypeScript. I think you are trying to justify changing TypeScript into something that isn't TypeScript. Sorry to be so direct.

[duanyao]

@kitsonk Be calm, I think you misread my point completely.

I definitely love strong type and the tooling support of TS, or TS couldn't become my major programming language. However, type assertion(or casting) is definitely not the beautiful part of any strongly typed languages; instead, it is the enemy of type safety and OO. If a language(or a library) requires developers to write a lot of type assertions (and in a verbose way), I would say something is sub optimal here.

The standards (I think you are referring to DOM and WebIDL etc.) are language neutral, and more or less aligned to JS. I think there is nothing wrong to adjust the interfaces of a concrete language slightly to match the real use cases, instead of 100% direct mapping to the standards. TS has already do this in lib.d.ts.

Does this issue have nothing to do with DOM? The reporter talked about window object and jquery, so I'd assume this issue came from DOM programming. Finally, the reporter and RyanCavanaugh also talked about high-precedence type assertion, which is also a problem I care about.