Dear Boost,
One of the arguments against policy types stemmed from the subtle
issue with things like `char_traits` and `Allocator` being template
arguments: they spawn new types which may not be interopable. There is also
the argument that "vocabulary types should be singular, concrete types".
One of the great strengths and principals of C++ is having *decent*
performance by default and choosing a default that most people can interop
with (e.g., it is the safest or the most common vocabulary spelling) while
letting users who care (which tend to be a lot of people in their own
application-specific trenches) pick what makes sense for them.
As it stands, we probably should have standardized a
basic_variant and basic_optional before defining
hard structs which inherit all member functions (struct variant:
basic_variant { /* */ }; and friends) to create sensible
defaults for the community. At the cost of more up-front work, this would
have saved us a great deal of effort and time in this domain by giving a
decent default to interop with between libraries while giving the people
with concerns for reaching the local maxima of their (private) ecosystems
the chance to do so without rolling variant2 or optional.v3 or Yet Another
Expected/Outcome Type.
As a library developer, it's hard to not have just The One Variant
Type because it makes writing APIs a bit difficult if you can't template on
Policy. On the other hand, it's infinitely frustrating as both a library
developer and an application developer when there's only one type and I
only need to tweak some small bit of its behavior but instead have to roll
an entirely new type and share absolutely no functionality with the
original, let alone have the ability to create a reasonable
constructor-based interop story.
I think in the future we will start settling closer and closer to
having customizable types where it makes sense. There's too much good
design and performance and memory being dropped on the floor otherwise.
Sincerely,
JeanHeyd Meneide