P2727 R4 std::iterator_interface

[wg21bot]

P2727R0 std::iterator_interface (Zach Laine)

[brycelelbach]

2023-01-17 Library Evolution Telecon

P2727R0: iterator_interface

2023-01-17 Library Evolution Telecon Minutes

Champion: Zach Laine

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Start: 2023-01-17 11:06 Eastern

Does this paper have:

• Examples?
  • Yes.
• Field experience?
  • Yes, but not from spec and not in the Standard Library.
  • The proposal is based on facilities from the Boost STL Interfaces library.
• Performance considerations?
  • No.
• Discussion of prior art?
  • Yes.
  • view_interface is prior art in the Standard Library.
  • Boost Iterator Facade/Adaptor was proposed as N1530.
• Wording?
  • No.
• Breaking changes?
  • No.
• Feature test macro?
  • Needs one.
• Freestanding?
  • It should be.

Open Questions:

• Is CRTP inheritance the best way to do this? Are there any alternatives (wrapper type, etc)? Does this sort of thing need a language feature (mixins, etc)?
  • There's existing practice for this in the Standard Library - view_interface.
• How does this compare to iterator, which we've deprecated?
• Is iterator_interface_access, the mechanism for providing private access to user's types, novel in the Standard Library? Is there any existing practice?
• How is this different from N1530? Why didn't N1530 get standardized?
• Is this worth standardizing if it's not robust enough and performant enough to be used for essentially all iterator implementations, including those within the Standard Library.

Key Insights:

• When the interface class is a dependent base class (e.g. the derived type is a template), names from the base class won't be injected. The paper should explore the implications of this.
• The performance implications of using these interfaces should be explored, such as:
  • Inlining.
  • Compilation time.
  • Debug build performance.
  • Impact on auto-vectorization.
  • Performance surprises or trade-offs resulting from how the generic operations in the base classes are implemented.
• access may be the wrong terminology for iterator_interface_access - it's already used in the standard library for a number of exception types (bad_variant_access, etc) and accessor.
• interface may be the wrong terminology. We should bikeshed other names. However, interface is the terminology with precedence (view_interface).
• The Ranges study group should see this.

Typos:

• In section 2.6: "you can simply provided that operation in your type", should say "provide" instead of "provided".

It would be nice if we could do using my_base_class::* and get everything.

End: 12:02

Summary

This paper proposes facilities to ease writing iterators. The facilities are CRTP base classes and other helpers.

We reviewed the general design in depth. One issue that arose was the usability of these facilities when they are dependent base classes and names from the base classes are not injected into the derived class.

We also discussed potential performance implications, including both run-time and compile-time concerns.

This paper is in the early stages, so we'll definitely be seeing it again.

Next Steps

Revise the paper according to the following guidance and return to Library Evolution for further review: