Yeah, I get what you're saying. You don’t want to clutter the code with an index, but when debugging, you suddenly wish you had it. Since you're dealing with a random-access container, you can definitely figure it out at runtime in the debugger.

If item is a reference, then yeah, the &item - &myarray[0] trick works because the elements are contiguous in memory. But if item isn’t a reference, then you'd need to reconstruct the position differently.

A few options:

1. Memory Address Trick (if item is a reference)

If the container is an std::vector<int> or similar contiguous structure, and item is a reference, then in the debugger (assuming GDB or LLDB), you can manually calculate:

(size_t)&item - (size_t)&myarray[0]

Dividing by sizeof(int) gives the index.

2. Watch the Iterator in a Debugger

Some debuggers (like MSVC) will actually track the iterator and show it in the watch window. In GDB, you can print the iterator’s distance from the beginning:

std::distance(myarray.begin(), std::find(myarray.begin(), myarray.end(), item))

This assumes no duplicates and that item is comparable.

3. Modify the Debugger to Track Iteration

If you're using MSVC, you can set a watch expression for something like _Container_base12::_Mylast (which tracks the last element in some STL implementations).

4. Enable Compiler Features for Debugging

Some compilers have options that retain iterator positions even in optimized builds, which can be helpful if you suspect an issue but can’t easily modify the code.

You’re right that std::views::enumerate would make this problem disappear at the cost of more complexity. But for pure debugging without modifying code, using memory addresses or debugger features is your best bet.