This is an archive of the discontinued LLVM Phabricator instance.

[llvm][ADT] Allow using structured bindings with `llvm::enumerate`
ClosedPublic

Authored by zero9178 on Aug 9 2022, 4:45 AM.

Details

Summary

This patch adds the ability to deconstruct the value_type returned by llvm::enumarate into index and value of the wrapping range. Main use case is the common occurence of using it during loop iteration. After this patch it'd then be possible to write code such as:

for (auto [index, value] : enumerate(container)) {
   ...
}

where index is the current index and value a reference to elements in the given container.


The order of index first, before value was mainly chosen to stay consistent with the current documentation of llvm::enumerate, but I'd personally be open to (and would have a slight preference of) swapping the order of the two as well.

Diff Detail

Event Timeline

zero9178 created this revision.Aug 9 2022, 4:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2022, 4:45 AM
Herald added a subscriber: StephenFan. · View Herald Transcript
zero9178 requested review of this revision.Aug 9 2022, 4:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2022, 4:45 AM
kuhar added a comment.Aug 9 2022, 7:52 AM

Neat!

The order of index first, before value was mainly chosen to stay consistent with the current documentation of llvm::enumerate, but I'd personally be open to (and would have a slight preference of) swapping the order of the two as well.

I'd *personally* prefer to keep it as index, value, because that's the order in python, rust, and swift.

llvm/unittests/ADT/STLExtrasTest.cpp
85–86

Can we also have a test that updates the value? I'm not sure if this is currently supported based on the get function.

Neat!

The order of index first, before value was mainly chosen to stay consistent with the current documentation of llvm::enumerate, but I'd personally be open to (and would have a slight preference of) swapping the order of the two as well.

I'd *personally* prefer to keep it as index, value, because that's the order in python, rust, and swift.

That's a very good argument as well. I shall keep the current state then.

llvm/unittests/ADT/STLExtrasTest.cpp
85–86

I did so already in line 81

zero9178 updated this revision to Diff 451154.Aug 9 2022, 8:01 AM

Fix a typo in one of the tests

kuhar added inline comments.Aug 9 2022, 8:01 AM
llvm/unittests/ADT/STLExtrasTest.cpp
84–87

We can simplify this sequence of checks to EXPECT_THAT(foobar, ElementsAre(4, 5, 6));

85–86

Can we move that test into this testcase then?

zero9178 updated this revision to Diff 451156.Aug 9 2022, 8:04 AM

Move modify test to corresponding test case

zero9178 updated this revision to Diff 451162.Aug 9 2022, 8:17 AM
  • Make use of ElementsAre
  • Also add test cases for rvalue refs.
zero9178 marked 3 inline comments as done.Aug 9 2022, 8:20 AM
kuhar accepted this revision.Aug 9 2022, 8:25 AM

Looks good to me, but I'm not 100% sure about const/ref correctness. Please wait for a second approval before submitting (e.g., from @dblaikie).

llvm/unittests/ADT/STLExtrasTest.cpp
46

nit: I think it's more common to have this just after using namespace llvm;

142

I'm surprised this doesn't require auto&& [index, value], but this seems consistent with the existing behavior with X.value()

This revision is now accepted and ready to land.Aug 9 2022, 8:25 AM
zero9178 marked an inline comment as done.Aug 9 2022, 8:41 AM
zero9178 added inline comments.
llvm/unittests/ADT/STLExtrasTest.cpp
142

The part before the structured bindings (here the auto) surprisingly does not apply to the destructed elements (index and value) but to the unnamed variable that the range assigns to.
This unnamed variable is essentially equal to what was X in the loop above, hence it also works with auto without issues.

The types of index and value are actually derived from the std::tuple_element specializations and the return type of get.

zero9178 updated this revision to Diff 451171.Aug 9 2022, 8:42 AM
zero9178 marked an inline comment as done.

Addressed Review comments

dblaikie accepted this revision.Aug 9 2022, 8:57 AM

Seems OK to me - thanks for checking!

This revision was landed with ongoing or failed builds.Aug 9 2022, 9:12 AM
This revision was automatically updated to reflect the committed changes.