Re: [boost] Mother of all Variants

On Thu, May 30, 2019 at 9:17 AM JeanHeyd Meneide via Boost < boost@lists.boost.org> wrote:

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.

Ugh, no. Things that behave differently should be named differently, and policies, tags, etc., should only be used for things that we can't name differently for other reasons (such as tags passed to constructors).

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.

Except that you have no idea what operations are guaranteed to be usable generically, and the moment you provide those guarantees (say by documentation), you cannot make any behavioral changes because you'll break the generic code. Take string for example: there are plenty of string classes out there which aren't specializations of basic_string, nor should they be. I much prefer the string_view approach, as that gives you the common operations w/o a tight coupling to some templated string class.

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.

basic_* doesn't solve that problem, because generic code may be dependent on that small bit of behavior. -- Nevin ":-)" Liber > +1-847-691-1404