As can be seen in the link below :

http://mir-algorithm.libmir.org/mir_algorithm_iteration.html

Libmir provides almost the same function as std. Why is benefit of doing that? Wouldn't it be better to not duplicate std stuff?

Erdem

On Friday, 1 May 2020 at 11:31:29 UTC, Erdem wrote:
> As can be seen in the link below :
>
> http://mir-algorithm.libmir.org/mir_algorithm_iteration.html
>
> Libmir provides almost the same function as std. Why is benefit of doing that? Wouldn't it be better to not duplicate std stuff?
>
> Erdem

I think duplication is for betterC support (in particular, avoid the GC).

On Friday, 1 May 2020 at 11:31:29 UTC, Erdem wrote:
> As can be seen in the link below :
>
> http://mir-algorithm.libmir.org/mir_algorithm_iteration.html
>
> Libmir provides almost the same function as std. Why is benefit of doing that? Wouldn't it be better to not duplicate std stuff?
>
> Erdem

Some benefits:

1. Mir API can handle elementwise ndslice (multidimensional random-access ranges created using Slice type). Phobos API handles them as random-access ranges. For example, Mir's `map` applied to matrix returns a matrix, Phobos returns a lazy range or fail to compile depending on the lambda.

2. Mir iteration API (each, all, any, and others) can handle multiple arguments at once without zipping them. It is critical for multidimensional performance.

3. Mir `zip` operation supports elementwise access by reference. It is critical in some cases.

4. some @nogc/nothrow fixes, some optimizations for move semantics, and BetterC code.

5. Mir strings lambdas have fused-multiply-add transformations enabled by default.

 ...  and more.

Sure, it would be better to do not to duplicate similar API.

Originally ndslice was in the std.experimental. However, it was impractical to maintain it in the std and I have moved it to the dub package. Mir is targeting to do not use std, except maybe std.traits and std.meta. We don't care about the name conflicts with std.

Ilya