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:

[inbal2l]

P2727R1 std::iterator_interface (Zach Laine)

[brycelelbach]

2023-03-21 Library Evolution Telecon

P2727R1: iterator_interface

2023-03-21 Library Evolution Telecon Minutes

Champion: Zach Laine

Chair: Fabio Fracassi

Minute Taker: Ben Craig

Summary

Sentinel support for random access iterator?

make operator-> optional?

• not an issue? follow up with Tomasz (would make Concepts checks return the wrong result)

Document the issues with deducing this / operator<=> does not work to simplify that code.

use advance/distance_to, ... as names for customization types?

Wrapped vs new iterators

Fix iterator categories to make sure that C++20 iterator categories are observed.

Next Steps

We will see a revision of the paper

[brycelelbach]

P2727R2 will be available in the 2023-05 mailing.

[FabioFracassi]

2023-06-14 Library Evolution Varna Meeting

P2727R3: iterator_interface

2023-03-21 Library Evolution Telecon Minutes

Champion: Zach Laine

Chair: Fabio Fracassi

Minute Taker: Robert Leahy

POLL: We agree on the design of P2727r3, provide wording for the next revision.

SF	F	N	A	SA
6	8	0	0	0

Outcome: Unanimous consent

Summary

We made sure that the previous feedback has been incorporated, and looked at the additional implementation experience.

We approved the design.

Next Steps

We will see a revision of the paper, that includes initial wording, with the goal of forwarding the paper.

[wg21bot]

P2727R3 std::iterator_interface (Zach Laine)

[inbal2l]

The next revision of the paper requires wording.

[wg21bot]

P2727R4 std::iterator_interface (Zach Laine)

[ben-craig]

2024-08-06 Library Evolution Telecon

P2727R4: std::iterator_interface

2024-08-06 Library Evolution Telecon Minutes

Champion: Zach Laine Chair: Ben Craig Minute Taker: Mark Hoemmen

Summary

Mostly didn't have time to discuss, but there were mentions of objections to the design, so we should ensure that those objections are heard in the next meeting.

Next Steps

Wording and design discussion. Look up reflector discussions involving std::iterator_interface.