Skip to content

Conversation

@hepiyellow
Copy link

@hepiyellow hepiyellow commented Aug 10, 2024

Ternary expression optimization relays on "correct" types.
TypeScript language allows Type Assertions to be used, which allows "incorrect" typing when the developer find it suitable.

Usually you could find Type Assertions used in small code pieces where a the developer "known what they are doing" and the developer write the code that can handle the "correct" run-time type.

The problem is that due to Ternary Optimization, the transpiled LUA code will NOT behave as the developer expects, even if they write the code while considering the "correct" type !

Related to this Issue

@Perryvw
Copy link
Member

Perryvw commented Aug 11, 2024

There is no caveat and no difference with 'regular' TypeScript: if you provide an incorrect type assertion you are going to risk runtime errors.

I don't see how this is any different or how this adds anything to our documentation.

@Perryvw Perryvw closed this Aug 11, 2024
@hepiyellow
Copy link
Author

hepiyellow commented Aug 11, 2024

@Perryvw
I think you missed the point.

  • There IS(!) a difference from "regular" TypeScript.
  • Providing "incorrect" type assertion is a legitimate tool in TypeScript, as long as you "Know what you are doing", and you write the code considering the "correct" type.

The runtime errors I am talking about are NOT due to the "incorrect" type, they are due to the Optimization which has a side-effect when types are not "correct".

  • Did you read the example?
  • I also updated the description of this PR, maybe you'll find some reason in there.

@Z3rio
Copy link
Contributor

Z3rio commented Aug 11, 2024

Yeah, there is indeed an actual issue with the output, if compared to normal TS.

Whether that is something we actually want to / need to fix, or whatever, I'll leave up to you Perry.

See the console output for tstl code:
https://typescripttolua.github.io/play#code/MYewdgzgLgBBIFsCmB5ARgKxgXhgbwF8YYBDCfGMcAUQA8BLaesAcwGkkBPALkoFcEaJACcYBAFChIsWjhhRhfJDAD8cRKkwA6KmDqMozdlxi8ArOIAOw5lAAUAIloOANDFoBKcUA

x	5

And then see it for normal ts code:
https://www.typescriptlang.org/play/?#code/MYewdgzgLgBBIFsCmB5ARgKxgXhgbwF8YYBDCfGMcAUQA8BLaesAcwGkkBPALkoFcEaJACcYBAFChIsWjhhRhfJDAD8cRKkwA6KmDqMozdlxi8ArJPDwANki3WQLABQAiWi4A0MWgEogA

[LOG]: "x",  undefined 

@hepiyellow
Copy link
Author

@Z3rio thanks.

@Perryvw You wrote:

"if you provide an incorrect type assertion you are going to risk runtime errors"

as you can see the runtime error wouldn't occur because someObj.nonExistingKey is undefined (and the "correct" type said it IS defined), it would occur because x is 5 and not undefined.
The code doesn't risk anything, because it could deal with x=undefined.

const someObj = {}  as { nonExistingKey: number }
let x = trueAtRuntime ? someObj.nonExistingKey : 5
// Here the developer thinks that in case `trueAtRuntime=true` then `x=someObj.nonExistingKey`

// Now the developer handle the case where  `nonExistingKey` would actually be undefined. As you can see the developer is using Type Assertion with Caution.
if (x === undefined) {
  x= DEFAULT_VALUE
}
// But because of the Ternary optimization, `x=5` which is totally unexpected !
print("x", x)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants