feat: todo syntax

[qazxcdswe123]

No description provided.

[peter-jerry-ye-code-review]

From the provided git diff output, it appears that two files were modified to include a new section titled "Special Syntax" or "特殊语法" (depending on the language), which introduces the TODO syntax using .... Here are some potential issues or suggestions based on the context provided:

1. Incomplete Function Implementation:

   • The todo_in_func function in both the English and Chinese versions of the documentation returns an Int but contains only ..., which suggests an incomplete implementation. This could mislead readers into thinking that ... is a valid way to define a function's body in MoonBit, which might not be the case.
   • Suggestion: Clarify that ... is a placeholder for future implementation and not valid code that can be executed. Consider providing a note or example of how to properly mark incomplete functions or sections of code in MoonBit, if applicable.

2. Documentation Consistency:

   • Both the English and Chinese documentation sections introduce the TODO syntax similarly but without much context on its usage or limitations. It's crucial for documentation to be clear and consistent across different languages.
   • Suggestion: Ensure that all documentation sections, especially those introducing new syntax or features, provide comprehensive explanations, usage examples, and any caveats or limitations. This helps maintain consistency and clarity for all users, regardless of their preferred language.

3. Potential Misinterpretation:

   • The TODO syntax might be confused with a placeholder or a feature that automatically generates code or throws a compile-time error for incomplete implementations. It's important to clarify its intended use, such as marking areas for future work or as placeholders during development.
   • Suggestion: Explicitly state the purpose of the TODO syntax and how it should be used. For example, clarify if it is meant for developer notes, placeholders for future code, or if the compiler treats it in a specific way (e.g., generating a warning or error).

Given the context and the provided diff, these suggestions aim to improve clarity, prevent potential misinterpretations, and ensure consistency across different language versions of the documentation.