(nevermind, I misunderstood the issue)

I disagree here. You are giving an incorrect type to your object here. If it is ever possible that this key is not here, the object should be typed as { nonExistingKey?: number }, which will result in the long-form version.

In general we will always err on the side of caution and use the non-optimized version, but if you tell the compiler for sure the type of this thing is this, and at runtime it is something else, the problem is in your code, and not in TSTL.

If we are to accept your approach, then it should be stated clearly in TSTL docs that using Type Assertion ( my_variable as ...) is NOT SUPPORTED or MAY LEAD TO RUN-TIME ERRORS!

I remind you that:
"Type assertions are a way to tell the TypeScript compiler that you know the type of a value better than it does. They are a form of type casting, but unlike other languages, they have no runtime impact in TypeScript. They are purely a compile-time construct."

A developer using TSTL - MUST ACKNOWLEDGE that Type Assertion may have runtime effects.

I just want to remind here , that in the case I presented above, the runtime error was not due to the "wrong" type being asserted on someObj, meaning, not due to the fact that nonExistingKey was undefined, but rather from an apparently unrelated optimization. If this code was transpired to Javascript this wouldn't cause an error.

So you would want x to be undefined in this case even though you asserted the type of nonExistingKey to always be a number and not undefined.
As @Perryvw mentioned this does not make sense.
You should not assert the type of number if the value in runtime could be undefined.
That defeats the purpose of typings in the first place.

from a high level, it kind of makes sense that the Lua output would depend on what the types are.

take a simple example:

• in typescript, we have [] for arrays and {} for objects.
• in lua, we have {} for both arrays and objects.

thus, the compiler would have to use the types in order to create coherent output.
if you think the docs need to be improved, submit a PR to this repo: https://github.com/TypeScriptToLua/TypeScriptToLua.github.io

@Zamiell

In the Array vs Object case, it is a matter of correctness.
In the Ternary case, it's a matter of optimization.

My approach would be to keep to a minimum the dependency of the transpiling on the types, and thus, like TypeScript, the developer can be SURE that changing types will not have any run-time implications.

I cases like Arrays vs Objects, it might be a necessity. But optimizations are not necessary.

@Zamiell

It is kind of hard to document this behavior, Does this sound right?

Avoid Type Assertions

"Due to some optimizations which depend on type correctness, you should keep in mind that using Type Assertions may have an effect on transpiled code, and can in some cause unexpected behavior. We recommend that you don't use Type Assertions"

You may even want to prevent Type Assertions completely, by using ESLint with a rule such as:

{
  "rules": {
    "@typescript-eslint/consistent-type-assertions": ["error", {
      "assertionStyle": "never"
    }]
  }
}

@Zamiell
I created this PR