Re: Mother of all Variants

From: Nevin Liber (nevin_at_[hidden])
Date: 2019-05-30 17:48:01

On Thu, May 30, 2019 at 9:17 AM JeanHeyd Meneide via Boost <
boost_at_[hidden]> wrote:

>      As it stands, we probably should have standardized a
> basic_variant<Policy, ...> and basic_optional<Policy, ....> before defining
> hard structs which inherit all member functions (struct variant:
> basic_variant<rarely_empty, ...> { /* */ }; 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  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
[phone]