[PATCH] D48348: [ADT] Add zip_longest iterators.

[David Blaikie via llvm-commits]

Nah - I was thinking of something where zip wouldn't need any changes,
potentially. One possibility:

    * iterator adapter that takes a (potentially finite) range of T and
produces an infinite range of Optional<T> (with elements beyond the
original range being empty Optionals)
    * same as the above, except potentially finite range of T to an
infinite range of T where the elements beyond the original range are
default constructed
    * A range truncation helper that just does something like:
iterator_range trunc(R r, size_t t) { return {adl_begin(r),
std::next(adl_end(r), t)}; }
    * then you do something like: trunc(zip(inf_opt(R1), inf_opt(R2)),
max(size(R1), size(R2)))

This allows the use of these infinite/padded ranges in other situations
apart from zipping.

But maybe that's niche enough/not worth generalizing over pre-emptively.
I'm not sure. Just a thought.

On Mon, Jun 25, 2018 at 5:40 PM Michael Kruse via Phabricator <
reviews at reviews.llvm.org> wrote:

> Meinersbur added a comment.
>
> Is the following what you are thinking about?
>
> An `zip_infinite` begin-iterator, that never reaches the end (maybe with
> two flavors: `zip_infinite_default` and `zip_infinite_optional`) and return
> a `None`/value-initialized value for any iterator past the list. Then one
> can use that with an end iterator, such as `end_any` (-> zip_shortest) or
> `end_all` (-> `zip_longest`).
>
> Unfortunately, in the `zip_infinite_default`-case, we cannot distinguish
> between the default value end the end of the list. We'd have to look into
> the iterator's list of iterators, which makes this implementation-specific
> again.
>
> Alternatively, `zip_infinite` could return tuples of iterators, which
> `end_any`/`end_all` could compare to the end iterators. However, the
> current implementation of `zip_shortest` does not need to store the
> end-iterators for `operator++` (because in contrast to the others, it does
> not need to check whether one of the sequences is past the the end), making
> the implementation less efficient than it needs to. (template
> specialization of `shortest_iterator<zip_infinite<T>>` maybe?)
>
>
>
> ================
> Comment at: include/llvm/ADT/STLExtras.h:757-785
> +template <typename... Args> class zip_longest_default_range {
> +public:
> +  using iterator = zip_longest_default_iterator<decltype(
> +      std::begin(std::declval<Args>()))...>;
> +  using iterator_category = typename iterator::iterator_category;
> +  using value_type = typename iterator::value_type;
> +  using difference_type = typename iterator::difference_type;
> ----------------
> The `zip_*_range` classes (including `zippy`) might no be needed:
> `iterator_range` could be used as well.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D48348
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180625/cdf3e761/attachment.html>