golang 一个很神奇的问题

[ysz1121]

有谁能帮解释一下这是啥原因？

使用 strings.TrimLeft app- 的a哪去了？

[learningman]

居然有人发现行为不符合预期的第一反应是怀疑标准库，也许这就是大师吧

[realpg]

@learningman #21
好不容易学会了 github 提 issue 总得找个地方试试

[dyllen]

这么基础的库，用了那么多年了，怎么可能有这样低级的错误

[dobelee]

trim 都是用字符集合吧，golang 之外也是一样的。
这么常用且实现简单的标准库函数，开局就是一个 issue 。😅

[Jirajine]

@dobelee #24 不一样。把 string 当做 char set ，要么是 API 设计有问题，要么是语言类型系统不足是这种设计成为常规做法。
比如 rust 里类似的函数就没有这种坑 https://doc.rust-lang.org/std/string/struct.String.html#method.trim_start_matches
它的参数类型是 Pattern ，可以是 char/&[char]/&str/fn ，而不是一个当做 char set 的 string 。

[flyqie]

你但凡翻下函数签名。。。

func TrimLeft(s, cutset string) string

是 cutset 而不是 prefix 。。。

[flyqie]

@Jirajine #27

这个应该不是 bug ，真要怪的话。。怪设计吧，个人觉得这个函数应该用切片比较合适，直接上个 string 的话确实可能会误导。

[iseki]

@dobelee 反正我的话确实只在 Go 里见到了这样的设计，以至于 Go 里所有的文本相关函数我都长了个心眼，其它语言有哪些类似的设计吗？可以举一下，确实没见过

[westoy]

@iseki

php 的 trim
c#的 Trim
python 的 str.strip
ruby 的 str.delete
java apache commons 的 StringUtils.strip
koltin 的 trim

[largezhou]

trim 都是这样的，不过我们之前代码中也出现了类似的错误用法

[ysz1121]

感谢大佬们的讲解，学习了！

[bruce0]

@flyqie #27

>这个应该不是 bug ，真要怪的话。。怪设计吧，个人觉得这个函数应该用切片比较合适，直接上个 string 的话确实可能会误导。

我觉得你这个可以提个 issue 🤣

[PTLin]

@bruce0 op 这种人其实不少，我以前见过一个人碰到问题第一反应就是去论坛，issues 里提问，而不是自己尝试解决，甚至没人给他解决的话他就喷这个东西设计的有问题，喷这个东西垃圾。。。

[bruce0]

@PTLin 参与过几个开源社区, 这种遇到的不多, 大多数人还是挺友好的, 如果帮助他们解决了问题, 一般都会感谢, 没解决也不会抱怨, 毕竟大多数社区都是用爱发电的.

上上周吧, 我在用 redis 的时候, 发现 acl 的 rule 重写有点问题, 全网 acl 相关的文章太少了(不论中文还是英文) 官方文档也没有 相关的解答, 我就去 redis 社区, 提了一个 issue

先把我遇到的问题,redis 版本, 复现路径 描述了一下, 然后说了我预期的结果, 就怕不是 bug 闹了乌龙, 丢人丢到国外去, 社区的那个大佬 回复挺快的, 第二天就回复 是个 bug, 晚上顺手就给修了

[iseki]

@westoy kt 的 trim 那是个 predict ，jac 的那个确实是个 string

[flyqie]

@bruce0 #32

哈哈哈，issue 提了也没啥用啊，标准库都已经这样了提 issue 也改变不了设计啊，不然兼容性直接打破了🤣。

我唯一能想到的不用切片的理由就是。。字符串可能性能比较好容易做 cache ？但好像标准库也没 cache 啊。。

[cooltechbs]

楼主写 Go 多久了？ Go 相比 C++、Java 之类的语言，一大好处就是标准库代码都摆在明面上（安装就有），也含有和官网一样的文档，查阅非常方便。RTFSC 对于 Go 开发者应该不是玩笑，是日常。