You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"If this was intentional, convert the expression to 'unknown' first" diagnostic should come with a codefix #28067
My fix for this issue is coming along nicely. In fact, I had finished and tested it before I noticed you wanted this to apply to TypeAssertions as well as AsExpressions. So I'm working on adding that functionality. Just to verify, <string>0 should codefix to <string><unknown>0?
I'm hoping you can clear up some confusion I'm having with this solution. I don't find the double assertion first to unknown and then to the type we want to be very elegant or even consistent with documentation.
The basic basic types docs mentions in the type assertion section
Type assertions are a way to tell the compiler “trust me, I know what I’m doing.” A type assertion is like a type cast in other languages, but performs no special checking or restructuring of data. It has no runtime impact, and is used purely by the compiler. TypeScript assumes that you, the programmer, have performed any special checks that you need.
Doing a double cast seems to go against the whole "trust me, I know what I'm doing" theory behind type assertions. Is the reason for this a technical limitation with the typescript compiler?
Thanks for the response. I hope your team will reconsider this approach.
The syntax is ugly and would turn me away from typescript if I was a beginner
Violates the idea the programmer knows what they are doing over the compiler.
This seems to be the equivalent to having a double confirmation dialog in a UI. In this analogy I imagine a pop up box asking a user if they accept terms and conditions, and when they hit accept they are prompted again if they are sure they accept the terms and conditions.
Just as that double confirmation is not a good user experience in a UI, having to double assert what you want is not a good user experience when programming.
Reacted by Byron Dover, Mohamed Aymen Hammemi, JanAmbrozic, Lukas VI, Cromat, Alex Nozdriukhin, gustavol3v, Jacek Pakulski, filipwalczak, Jason Yoon and 5 more
Activity
ryanclarke commentedon Oct 25, 2018
I'm interested in taking this issue. Any pointers you think would be helpful for a first-time Typescript contributor?
ryanclarke commentedon Oct 29, 2018
My fix for this issue is coming along nicely. In fact, I had finished and tested it before I noticed you wanted this to apply to TypeAssertions as well as AsExpressions. So I'm working on adding that functionality. Just to verify,
<string>0should codefix to<string><unknown>0?itmayziii commentedon Dec 30, 2018
Andy (Andrewkraft) (@Andy-MS)
I'm hoping you can clear up some confusion I'm having with this solution. I don't find the double assertion first to unknown and then to the type we want to be very elegant or even consistent with documentation.
The basic basic types docs mentions in the type assertion section
Type assertions are a way to tell the compiler “trust me, I know what I’m doing.” A type assertion is like a type cast in other languages, but performs no special checking or restructuring of data. It has no runtime impact, and is used purely by the compiler. TypeScript assumes that you, the programmer, have performed any special checks that you need.Doing a double cast seems to go against the whole "trust me, I know what I'm doing" theory behind type assertions. Is the reason for this a technical limitation with the typescript compiler?
DanielRosenwasser commentedon Dec 30, 2018
It's "trust me I know what I'm doing" within means. We try to ensure there's some overlap, and if not you can do jump up and down the type hierarchy.
itmayziii commentedon Dec 31, 2018
Thanks for the response. I hope your team will reconsider this approach.
This seems to be the equivalent to having a double confirmation dialog in a UI. In this analogy I imagine a pop up box asking a user if they accept terms and conditions, and when they hit accept they are prompted again if they are sure they accept the terms and conditions.
Just as that double confirmation is not a good user experience in a UI, having to double assert what you want is not a good user experience when programming.
ackvf commentedon Feb 24, 2019
I hope we can switch this off in
tsconfig.