'An Approach to Dealing with Reference Types in the Generic Programming Paradigm'

—
—
When specifying datastructures using the generic programming paradigm, we explicitly require or assume certain properties of our input types. For instance, in order for a standard container to make sense, you should give it a type that is at least some non-conflicting subset of the Regular concept. Your value type should be movable, and if it is copyable and copy-assignable as well, the semantics of those operations should be consistent in meaning with those of a Regular type. Violating these requirements results in code that will either not compile at all, or will have semantics that may be both useless and totally inconsistent with other instantiations. In brief, don't attempt to create a vector of a reference type or a vector of a proxy type such as vector＜bool＞::reference.

And yet despite that totally reasonable restriction, we sometimes encounter real-world, higher-level generic code that *seems* to need or want to be able to use generic datastructures with reference types or proxy types. Is this higher-level code simply in error and in conflict with generic programming principles, or are the details a bit more subtle? In this session, we will examine such cases and deduce what the expected semantics in such code actually is. We will further explore how it is that we can develop our datastructures of the future in a way that works not just with Regular objects, but with reference types and proxy types as well, and without making the existing semantics of our generic datatructures weaker or parametric.

Audience participation is encouraged and should lead to discussions. This session is expected to be controversial, but constructive for all library developers.
—
Matt Calabrese is a software engineer working primarily in C++. He started his programming career in the game industry and is now working on libraries at Google. Matt has been involved with the Boost community for over a decade and is currently a member of the Boost Steering Committee. He has been attending C++ Standards Committee meetings since 2015, authoring several proposals targeting the standard after C++17, notably including a proposal to turn the void type into an instantiable type.
—
---

*--*

---

[BlairDavidson]

Good talk. How would you go about dealing with pointers and shared_pointers etc that do dont support the dot operator. Would you use a trait like what you were proposing for Additive or create a wrapper type that models T and delegates calls to the pointer / shared pointer