Re: Mother of all Variants

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2019-05-30 23:20:43

On Thu, May 30, 2019 at 1:48 PM Nevin Liber via Boost
<boost_at_[hidden]> wrote:
>
> 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]>>

Exactly.
- The point of vocabulary types is to be a type that can be passed around.
- Same name == same behaviour because templates run on names, and
expect same behaviour (as do users)

Alexandrescu had a policy based smart pointer.  Boost didn't, and it was good.

Tony