Should `protocol<I>` conform to `I`?
- Dominant language
- C++
- Stars
- 11
- Forks
- 4
- Avg merge
- 16h 39m
- Merged PRs (30d)
- 131
Description
Split from #229, which #244 resolves by adding view constructions only.
`is_protocol_conformant>()` remains `false`: the synthesised members of `protocol` are data members holding thunk objects, not member functions, so `conformance_candidates_of` never sees them.
#244 originally made `protocol` conform to `I` when `J`'s vtable has an entry named by the mangled signature of every member function of `I`, but review scoped this out:
- constructing a `protocol` or `protocol_view` from a conforming `protocol` with `J != I` forwards every call through two vtables and chains unboundedly with each wrapping (https://github.com/jbcoe/cc-protocol/pull/244#discussion_r3892858236)
- it is unclear whether the trait itself is wanted (https://github.com/jbcoe/cc-protocol/pull/244#discussion_r3893054436)
Decide whether the trait should hold (and for which candidates), and what construction, if any, it should enable.
Contributor guide
Research direction
Start with is_protocol_conformant> and conformance_candidates_of, then read the scope and review discussions in #229 and #244. Determine which protocol candidates and constructions the trait should cover; done means an agreed design and corresponding behavior, with the risks around chained vtables addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100