Tracking issue for extra linked list methods

[alexcrichton]

This is a tracking issue for the unstable linked_list_extras methods in the standard library.

cc @Gankro, perhaps you can fill this in some more? The specific methods in question are:

• IterMut::insert_next
• IterMut::peek_next

[Gankro]

This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.

[steveklabnik]

Triage: these are still unstable.

[dtolnay]

There are some ideas for a more complete IterMut API in #39148 (comment).

[dtolnay]

IterMut::peek_next seems misnamed. Doesn't it do exactly what we call peek() elsewhere?

[Amanieu]

I'm going to echo @Gankro's thoughts:

This is basically a lame version of cursors, which is what we should use instead imo.

An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range.

A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection.

I strongly oppose adding insertion/deleting methods to IterMut since they do not fit at all with existing iterator usage patterns (for loops and functional-style methods).

As I mentioned in the linked thread, a design based on the Cursor and CursotMut types in intrusive-collections could be used.