DuDaoDong
DuDaoDong
> 已修复 测试任务还是失败。
> > > 已修复 > > > > > > 测试任务还是失败。 > > 方便告知哪里错误吗 点击任务日志，只能看到如下图：，你可以在promise目录下执行：go test promise.go promise_test.go 看看能不能通过。如果通过，可能是github action的问题。
> > go test promise.go promise_test.go > > 已经通过 单侧任务报以下错误：
> > go test promise.go promise_test.go > > 已经通过 你用的go版本是不是1.19, lancet的go版本是1.18，里面没有sync/atomic这个包。
> Promise由于其特殊性，必须是pin的，不能够移动在内存中的位置，所以new函数返回一个Promise指针依旧有可能不安全，且_sync.Mutex和_sync.WaitGroup虽然为了内存不可移动声明为指针类型，但是占用了更多内存，且*sync.Mutex是不必要的，建议将代码修改为如下布局，更安全，并节约资源 > > ``` > type Promise[T any] struct { > *promise[T] > } > > type promise[T any] struct { > runnable func(resolve func(T), reject func(error)) > result...
@supermigo，可以尝试提PR修复，近期工作比较忙，精力有限。
> 入别名 @CcccFz lancet中有很多重名方法(例如slice/filter, maputil/filter), package的作用一是代码复用，二是做命名空间。go不支持命名空间语法。兼容性很重要，2种方式都需要支持。如果所有方法都在一个lancet包下，需要导入所有对应的子包，然后定义对应方法的包全局变量。针对重名方法还要重新命名。代码复杂度增加，维护困难，投入产出比低。
This issue requires us to be able to access all functions in the Lancet library using the lancet.XXX() syntax, rather than importing numerous corresponding packages. I would like to discuss...
> I don’t think it’s a good idea to support this requirement. On the one hand, users can encapsulate a toolkit themselves to wrap commonly used lancet utility functions. On...