Implement iter_arc method for List

[PoulavBhowmick03]

Fixes #70

Introduced method iter_arc:

• Created a new type, ArcIter in iter_arc.rs
• The iter_arc method iterates over and gets each element of the List wrapped in Arc<T>.
• Added the method to the List impl in list.rs

[PoulavBhowmick03]

@michaelsproul is this a good start? do let me know

[michaelsproul]

Yeah this looks good. I wonder if we could write the ordinary Iter as a wrapper around IterArc? This would save on code duplication.

[michaelsproul]

It would be great to add a new Op to the proptests as well:

milhouse/src/tests/proptest/operations.rs

Lines 210 to 212 in e1c9a57

	Op::Iter => {
	assert!(list.iter().eq(spec.iter()));
	}

However it would have to run conditionally on T::tree_hash_type() not being Basic.

[michaelsproul]

Needs some merge conflicts resolved, I've just been preparing a v0.7.0 release

[PoulavBhowmick03]

Needs some merge conflicts resolved, I've just been preparing a v0.7.0 release

No problem. Fixing it

[PoulavBhowmick03]

@michaelsproul fixed the conflict and the clippy warning

[michaelsproul]

Thanks, will review thoroughly and probably merge tomorrow. Looked good at a glance

[michaelsproul]

I think this might be wrong in the case where there are pending updates. The proptest should have caught this

[PoulavBhowmick03]

I was thinking to change it to use ArcInterfaceIter, which handles the pending updates. But in that case, I will have to change the ImmList<> and include <U: UpdateMap<T>> to it. what would you suggest is the way to go about this?

[michaelsproul]

This should not be necessary, we should make iter_arc work without it

[michaelsproul]

The reason being: requiring the caller to keep track and flush pending updates in order for a method to work makes it a footgun. Take a look at InterfaceIter to see how it handles the pending updates. We can do the same for ArcIter.

Eventually I'd like to rethink how pending updates are handled in Milhouse, but I've gotten a bit stuck on previous attempts, see:

• Interior mutability #50

[PoulavBhowmick03]

That makes sense, will take a look into this PR and how pending updates are handled in InterfaceIter as well

[michaelsproul]

Mmm, this is hard. I almost want to try implementing UpdateMap for BTreeMap<usize, Arc<T>> so that we aren't doing useless Arcing

[michaelsproul]

Thanks for your patience @PoulavBhowmick03 🙏 Left a few more review comments. Sorry they're a bit nitpicky but I think we're getting close!

[PoulavBhowmick03]

@michaelsproul I have addressed all the issues except for one, left a reply to that, above

[michaelsproul]

This is unfortunate because it's just creating a new Arc.

Maybe we could have this as a fallback impl, and for maps that support it (like BTreeMap<usize, Arc<T>> we can have an efficient impl). The problem will be overlapping impls. We could get around that with a new type like struct ArcMap<T>(VecMap<usize, Arc<T>>).

This is all turning out to be a bit complicated haha