regex - Erlang re 和 lists 索引基数的区别

Question

刚遇到这个奇怪的案例，违反了最小惊讶原则(尽管它可能是主观的)。

当使用 re:run/2 时，我获得捕获组的元组。下一行，我正在提取捕获的子字符串。令我非常惊讶的是，这两个操作之间的字符索引不一致。 re:run/2 的 CaptureData 是从 0 开始的，而 lists:sublist/3 是从 1 开始的:

172> Line = "8#123abc#".                  
"8#123abc#"
173> re:run(Line,"^(\\d+)#(.+#$)").
{match,[{0,9},{0,1},{2,7}]}
174> lists:sublist(Line,0,1).
** exception error: no function clause matching lists:nthtail(-1,"8#123abc#") (lists.erl, line 180)
     in function  lists:sublist/3 (lists.erl, line 345)
175> lists:sublist(Line,1,1).
"8"

有人知道如何解释这种令人惊讶的不一致吗？抱歉，如果这个问题更多的是关于解决问题的哲学(这里的解决方案很明显)。

Answer 1

不幸的是，由于历史原因，OTP 库有很多 API 不一致。 Erlang/OTP 非常重视向后兼容性，不幸的是，这也意味着糟糕的 API 需要非常非常长的时间来修复。如果有的话。

类似不一致的一些例子:

• string 的名称和 queue模块是单数名词与用于 lists 的复数名词或 maps .
• string模块使用基于 1 的索引，而 binary使用基于 0 的。
• 如果你想从 dict 中查找一个值或 map ，您将键作为第一个参数传递，将集合作为第二个参数传递。对于 ets表格参数的顺序是相反的。

顺便说一句，Elixir 为在其标准库中创建一致的 API 做出了巨大努力。

关于您发现的这个特定问题:我猜 string模块使用基于 1 的索引，因为字符串实际上是代码点列表，而 lists模块也使用基于 1 的索引(但我不知道为什么)。至于re ，它可能使用基于 0 的索引，因为二进制文件使用它，我认为正则表达式匹配是在二进制文件上完成的，而不是列表(正则表达式代码基于 libpcre，一个 C 项目，所以它使更多在这里使用二进制文件和基于 0 的索引是有意义的)。