Feature Differences Between ArkTS and TypeScript
ArkTS has standardized constraints on TypeScript features that are overly flexible and may compromise development correctness or introduce unnecessary runtime overhead. The following code snippets illustrate some of these constrained features.
1. No support for changing object layout at runtime
The provided TypeScript code snippet demonstrates how to change the layout of an object by adding and removing properties at runtime. Supporting such features at runtime incurs significant performance costs. As such, ArkTS does not support such changes.
In ArkTS, you can use optional properties or assign undefined to the properties as an alternative.
2. Typed object literals
The provided TypeScript code snippet shows a scenario without type annotations. If the compiler is unaware of the exact type of the variable point, it cannot deeply optimize the code due to the uncertain object layout, leading to performance bottlenecks. Additionally, without type annotations, property types are not restricted. For example, while point.x is typed as number, it can also be assigned other types, resulting in additional runtime checks and overhead.
In ArkTS, object literals must be annotated with types.
3. No support for structural typing
The provided TypeScript code snippet demonstrates the feature of structural typing. Given that ArkTS has adopted a nominal typing system, adding support for structural typing would introduce unnecessary complexity for implementation. In the example, although the parameter type of foo is declared as C, a variable of type D can also be passed. This flexibility may affect program correctness. Moreover, due to different layouts of types D and C, the c.s property in foo cannot be accessed based on a fixed offset, thereby causing runtime performance bottlenecks.
