关于LSR-005的讨论

[inline-function]

点题

在现代编程语言设计中，类型前置和隐式转换通常被视为不佳实践，它们源于早期语言设计的探索，但如今已被许多现代化语言所摒弃或严格限制。其核心问题在于它们降低了代码的清晰度、安全性和可维护性。

类型前置：本末倒置的声明方式

类型前置语法（如 int a = 5;）强制开发者先关注类型，后关注逻辑主体（变量名或函数名），这是一种本末倒置的设计。

违背“名称优先”的阅读直觉：代码的首要目的是表达逻辑意图，而变量名和函数名是意图最直接的载体。冗长的类型信息前置会干扰开发者快速捕捉核心逻辑，降低代码的可读性与可扫描性。

与现代类型推断范式冲突：现代化编译器拥有强大的类型推断能力。类型前置语法与类型推断结合生硬（需引入 var 等关键字），而类型后置（如 a: int = 5 或 a := 5）则能与类型推断无缝融合，保持代码简洁。

不利于可变性标注：变量的可变性（const, let, val, mut）是定义其用途和安全性的关键属性，其重要性常高于具体类型。类型前置语法将更重要的可变性修饰符挤到次要位置。类型后置则能自然地将可变性关键字置于最前（如 const a: int = 5），引导开发者优先考虑变量的不变性，这是一种更优的默认实践。

隐式转换：埋下隐患的“便利”

隐式转换是一种危险的语言特性，它用微小的“便利性”换取巨大的潜在风险，是对程序健壮性的破坏。

破坏类型安全：隐式转换绕过了类型系统的检查，允许编译器静默地执行可能丢失精度或完全不符合逻辑的转换，这是许多难以追踪的运行时 Bug 的根源。

违背显式意图的原则：优秀的代码要求开发者的意图清晰明确。隐式转换掩盖了程序的真实行为，阅读者必须心智模拟复杂的转换规则，极大地增加了认知负荷和调试难度。显式转换（如 int(x)）虽然多写几个字符，却明确了意图，消除了歧义。

与面向对象原则背道而驰：子类型化（继承）是实现多态的正交方式，符合里氏替换原则。而隐式转换是一种非正交的、ad-hoc 的多机制，它常常破坏类型的抽象边界，引入意料之外的行为，是对良好设计理念的破坏。现代语言更倾向于通过清晰的子类型关系或明确的转换方法（如 .toString(), .toInt()）来规范类型间的操作。

[inline-function]

未优化的原文

点题

我完全不建议使用类型前置,以及添加隐式转换,它们是早期编程语言探索中留下的糟粕,在现代化语言中均被抛弃.

类型前置

类型前置粗暴的使开发者必须先考虑类型,而不是可变性,在现代化语言中,可变性的考虑比类型的重要,因为类型在编译器的完善下已经可以做到自动推导,但可变性难以推导且不应该被推导.添加渐进类型,是非常适合类型后置的,因为它作为一个标签可以随时去掉,以便规范推导式.再者,即使近期没有考虑可变性的问题,也要为后期考虑.

隐式转换

隐式转换是旧过程式语言不负责任的语法糖,新过程式语言不应该添加隐式转换,大部分现代化语言中,不再采用隐式转换,而是直接为原生类型构建子类型关系,里氏替换天然的满足了人们的想法,而违反里氏替换原则的隐式转换是对精确数学计算语言理论的一种毁坏.

[azhz1107cat]

确实
如果使用
var name: type = expr
代码对齐，可读性会更强
并且在编写时可以先确定名称再考虑类型，提高效率

[ExPuritate]

Implicit type casting could be used without problems you mentioned. For example, compiler could be designed to execute implicit type casting only when precision is not lost, e.g. i8 to i128. Compiler could support user-defined implicit type cast functions as well. But the 3rd point you mentioned is right I think.

隐式类型转换的使用不会产生你提到的问题。例如，编译器可以设计为只在不损失精度的情况下执行隐式类型转换，如 i8 到 i128。编译器还可以支持用户定义的隐式类型转换函数。但我认为你提到的第三点是正确的。
Translated by Deepl