-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify zip take 2 #27511
Simplify zip take 2 #27511
Conversation
5ed5cb8
to
b88cdc2
Compare
Apparently the DRY-fix was breaking inference, even on the current master. This PR with the last commit: > @code_warntype iterate(zip(1:2,1:2,1:2,1:2), (1,1,1,1))
Body::Union{Nothing, Tuple{NTuple{4,Int64},NTuple{4,Int64}}} Current master of Julia: > @code_warntype iterate(zip(1:2,1:2,1:2,1:2), (1,(1,(1,1))))
Body::Union{Nothing, Tuple{Tuple{Int64,Any,Vararg{Any,N} where N},Tuple{Int64,Tuple{Any,Union{Tuple{Any,Any}, Base.LegacyIterationCompat{_1,_2,_3} where _3 where _2 where _1}}}}} I don't yet see an easy way to test inference for |
You can use Compiler.typesubtract on the inferred type. |
…e tail of the subiterators; and make use of the macro to bail on nothing
b88cdc2
to
3317d44
Compare
I've added the commit of #27516 with an inference test of the new implementation of zip. Hopefully this can be merged soon :) |
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
Superseded by #29238 |
This pr:
Zip2
sinceZip1
is a valid base caseisdone
bug for theZip
iterator.iterate(zip(a, b, c))
returns((val_a, val_b, val_c), (state_a, state_b, state_c))
.isdone(z.b)
in the iterate function, since that is handled by recursion already when callingiterate(z.b, ...)
.y = produce(); y === nothing && return nothing; a, b = y
all over the place, which isa, b = @something produce()
with the macro. Yet I suspect people wouldn't like this macro in base, at least not with this name. Suggestions?