为何`trn`不在Pony语言的`#read`约束范围内？

#read约束的描述是“任何可从中读取的对象”，但实际仅允许ref、val和box，支持读取的trn却被排除，这背后的核心原因是#read的实际含义不止“可读取”，更关键的是支持无限制的别名操作。

关键能力特性对比 #

• ref、box、val：这三种能力都允许无限制别名——多个引用可以同时指向同一个对象，读取操作不会因为别名存在而受到限制，类型系统保证这类读取是安全的。
• trn：它的核心是独占可变性，虽然支持读取，但同时保证当前引用是唯一能修改对象的引用。为了维护这个独占性，trn不允许被随意转为其他支持别名的读取能力（比如box），也不能在保留可变权限的情况下创建别名。

约束设计的本质 #

当泛型使用#read约束时，代码隐含的假设是：可以对该类型实例进行任意读取和别名操作。如果允许trn加入这个约束，就会破坏这个假设——期望#read的代码可能会尝试创建别名，而这会直接违反trn的独占性保证，导致类型系统的安全机制失效。

实际测试也验证了这一点：在Pony playground中传入trn实例到带有#read约束的泛型时，会触发trn is not in constraint #read的错误，这是类型系统在严格维护约束的安全性边界。

内容的提问来源于stack exchange，提问作者Jeff Walker Code Ranger