Raku运行时`does`与`but`操作符混入Role的差异问询

本次讨论严格限定在运行时给具体对象混入单个Role的场景边界内，不涉及编译期类/角色声明的trait用法，也不涉及but搭配非Role值的特殊语义。

共性表现 #

当两个操作符都被用于给已实例化的普通对象混入单个Role时，核心行为确实高度一致：

• 二者都会基于原对象的类生成一个匿名组合类型，类型表现和实际测试中观察到的(Str+{R})格式完全一致
• 方法解析、类型检查逻辑无差异：对混入Role的类型匹配判断、方法调用的结果完全相同
• 匿名类型的缓存规则一致：多次对同一个值混入同一个Role时，会复用已生成的匿名类型，不会重复创建冗余的元类对象
• 值类型的处理逻辑一致：对Str、Int这类值语义的对象，二者都会返回带Role的新值，不会修改原变量指向的原始对象

容易被忽略的细微差异 #

上述相似性只覆盖了最基础的单值单Role场景，当扩展使用边界时，二者存在几个明确、可复现的行为差异：

1. 对类型对象（proto对象）的处理不同
   but支持直接在未实例化的类型对象上混入Role，会自动调用proto的默认实例化逻辑生成具体值，再追加混入的Role；但does严格限制只能作用在已实例化的对象上，对proto对象混入Role会直接抛出X::Cannot::MixinOnProto异常。
   可复现的测试代码：

   role R { method answer { 42 } }
   my $with-but = Str but R; # 正常执行，自动实例化为空Str并混入R
   my $with-does = Str does R; # 直接抛出异常，拒绝在proto Str上混Role
   

2. 运算符优先级不同
   根据Raku的运算符优先级定义，infix:<but>的优先级高于infix:<does>，这会导致连续写多个操作符时的解析顺序完全不同：

   role R1 { method mark { "R1" } }
   role R2 { method mark { "R2" } }
   # 优先级差异导致的解析结果不同
   my $x = "test" does R1 but R2;
   # 因but优先级更高，实际先将R1、R2组合为新的匿名Role，再对字符串混入该组合Role
   say $x.^roles; # 输出 (R1+{R2})，即单个组合Role
   my $y = "test" but R1 does R2;
   # 因does优先级更低，实际先将字符串与R1混合，再对结果混入R2
   say $y.^roles; # 输出 (R1 R2)，即两个独立的Role
   

3. 对非Role传入值的容错逻辑不同
   does的语义严格绑定Role操作，当传入非Role类型的参数时会直接抛出明确的类型错误；而but的设计兼容值语义，遇到非Role参数时不会报错，而是将其转换为布尔约束附加在原对象上（即已知的'question' but False这类用法）。

设计定位说明 #

这种核心功能重合、但语义边界和细节行为有差异的设计，正是Raku“同一类操作提供多侧重实现”的典型思路：

• does的定位是严格的Role契约操作：语义更贴近面向对象中“类/对象实现某接口”的严格定义，既支持编译期的静态混入，也支持运行时的严格混入校验，适合需要明确表达“当前对象实现了某Role契约”的场景
• but的定位是便捷的值增强操作：兼容更多边缘场景，允许快速基于已有值创建带附加能力/约束的新值，不需要严格遵循“必须实现Role”的前置校验，适合快速开发自定义字面量、带约束的值对象的场景

内容的提问来源于stack exchange，提问作者codesections