Replacement for Zip/Lockstep

bearophile bearophileHUGS at lycos.com
Mon Mar 17 05:36:27 PDT 2014


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


More information about the Digitalmars-d mailing list