monarch_dodra:
Thanks for the bug reports. I'll have to read them all in depth
to really appreciate them in depth.
If you do a quick search in Bugzilla perhaps you can find few
more of them.
I think you've convinced me to keep "shortest" as default, as
consistency is king.
In Haskell zip does the same as in Python and D:
Prelude> zip [1,2] [10,20,30]
[(1,10),(2,20)]
It *would* help to have short aliases to promote simpler usage
of each mode. Something like "zipShortest, zipLongest,
zipSameLength". For example.
Right. Another improvement could come from a little change in D:
enum E { A, B }
void foo(E x) {}
void main() {
foo(A); // "E." is implicit if there are name clashes.
}
I like 8715, I'll see if I can make it happen.
One advantage of 8715 is that you don't need to create tuples
first with zip and then something different with a map.
I'm just worried about having functions with 2 different
default parameters.
Right, this should be designed well.
Thinking about it harder, I'm wondering if it isn't possible to
actually have a Zip!condition coexist with the run-time
version. In which case, all I'd have to do is add the new
version. I'll see what I can do.
I'd like the run-time version to be deprecated and later removed,
to keep the API clean.
If not, the other idea is to alias `lockstep(condition)` to
return a `Zip`, and introduce a new and improved `lockstep`.
This works because (AFAIK), there is no publicly available
`Lockstep`.
If possible I'd like to keep only zip() and deprecate lockstep().
Time to start working!
Good :-) Zip is not at the top of improvements I'd like for
std.range/std.algorithm (near the top of my list there are issues
4705 and the already implemented but not merged issue 5550), but
making zip nothrow is going to be a nice improvement.
Bye,
bearophile
