Raku中Date/DateTime配合序列运算符(...)的语法合法性及异常问询

核心结论 #

你提到的语法本身在Raku中是合法的，但部分场景行为不符合预期：两侧均为DateTime时的报错是合理的；而左侧为Date、右侧为DateTime的情况属于设计缺陷，应当报错而非陷入无限循环。

分场景细节分析 #

1. 两侧均为DateTime对象：报错合理 #

序列运算符...的核心逻辑依赖元素实现succ方法生成下一个元素，同时需要能判断元素是否等于终止值。但DateTime类并未实现succ方法——它没有默认的“下一个时间单位”定义（DateTime精度到纳秒，不存在统一的“后继”规则），因此运行时抛出No such method 'succ'的错误是合理的，明确告知开发者DateTime无法直接用于序列生成。

对应报错代码：

DateTime.new("2022-03-26") ... DateTime.new("2022-03-28")

2. 左侧为Date、右侧为DateTime：无限循环属于设计缺陷，应报错 #

这种场景下无限循环的原因有两点：

• Date类实现了succ方法（返回下一天的Date），因此序列可以持续生成元素；
• Date和DateTime属于不同类型，即使代表同一时刻（比如Date.new("2022-03-28")和DateTime.new("2022-03-28")），类型不匹配会导致==判断永远为false，序列无法触发终止条件，从而无限运行。

从合理性来说，这种跨类型的序列生成应该提前报错，而非让程序陷入无意义的循环——开发者的预期是生成到目标日期，但类型不匹配导致终止逻辑完全失效。

对应无限循环代码：

.say for Date.new("2022-03-26") ... DateTime.new("2022-03-28");
.say for Date.new("2022-03-26") ... DateTime.new("2022-03-18");

与范围运算符(..)的对比 #

范围运算符..对日期/时间类型做了特殊兼容处理：它会自动将Date隐式转换为DateTime（午夜时刻），统一类型后再生成范围内的元素，同时能正确识别终止条件。因此跨类型的范围生成可以正常工作，输出符合预期的日期序列。

示例代码及输出：

.say for Date.new("2022-03-26") .. DateTime.new("2022-03-28")
.say for Date.new("2022-03-26") .. Date.new("2022-03-28")

输出：

2022-03-26
2022-03-27
2022-03-28

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