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