获取合并转发消息中的回复处理

[clansty]

接收转发消息 (IncomingForwardedMessage) 中的消息中消息段是普通的消息段，也就是说回复内容只有 seq、sender id 和 segments（在草案 #38 中） 这三个字段。然而：

• 回复的消息不一定在转发消息中包含
• 就算没有上一条，IncomingForwardedMessage 结构体也没有包含 seq 这个字段

也就是说，我们目前没有标准规定如何传递接收转发消息中消息回复的消息的发送人名称

[Wesley-Young]

问题是在合并转发消息中的消息回复中能拿到发送者的名称（至少是显示的名称，因为其对应的 srcmsg Elem 包含 9 号位，即完整的被回复的消息 pb），但在一般的消息回复中反而不包含名称（因为不包含 9 号位），规定的时候只考虑了后者

如果增加 name 字段的话，在解析一般消息的回复时必然涉及异步操作，虽然问题也没那么大就是了，毕竟大部分协议端都是缓存了成员列表的

[clansty]

那我们可以规定这个名称字段只在合并转发中需要有

[Wesley-Young]

你知道的，我不喜欢让某个字段“在某种条件下有，而在某种条件下没有”从而让其是 nullable

——除非情况所迫不得不这样，我觉得可以让他 nullable

[clansty]

原来是这样
那我们该怎么解决，难道是给获取合并转发加一个字段，是回复消息 seq 和消息的对应表（？

[Wesley-Young]

首先，给合并转发消息加 seq 属性，毕竟是可以拿到的，干嘛不往里加

其次，想了一下，被回复的消息的发送者的名称，可以有这个字段，规定成 nullable 的，但是 “什么时候不是 null，什么时候是 null” 不直接规定

[clansty]

我觉得 什么时候必须不是 null，是要规定的。可以是 null 的时候，下游应用就必须做好是 null 的准备，不然就会变成 onebot 那种乱象

[Wesley-Young]

会产生一种“教人写协议端”的现象

但话说回来，协议本来就是教人做事的东西，我采纳这个建议。