Re: [boost] [variant2] Review

Subject: Re: [boost] [variant2] Review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-17 12:24:03

wt., 16 kwi 2019 o 22:02 Robert Ramey via Boost <boost_at_[hidden]>
napisał(a):

> On 4/16/19 11:55 AM, Emil Dotchevski via Boost wrote:
> > On Tue, Apr 16, 2019 at 11:36 AM Robert Ramey via Boost <
> > boost_at_[hidden]> wrote:
> >>> It happens when the expert is so
> >>> uncertain in the most critical design choices
> >> Right - when concensus on design choices cannot be reached.
> >
> > Consensus is important only insofar as it is believed to lead to correct
> > design, but sometimes correctness and consensus differ. Correctness is
> what
> > matters.
>
> Hmmm - the problem is that there often multiple "correct" designs. That
> is, none can be proved to be "incorrect" in every context.  The notion
> of "correctness" is context sensitive.  One person might define having
> an empty state as "incorrect" while another might have another
> definition.  The problem here isn't making a "correct" design, it's
> agreeing on what is "correct"
>

Yes, I think policies reflect tat there exist different design trade-offs:
and one trade-off may be ideal for one group of people and the worse
possible choice for other people. Sometimes, if we are lucky, one trade-off
serves a great majority of users, so we can forget the policies. Sometimes
not, and then we either a number of similar types, or consider policies.
This has little to do with correctness.

In case of variant, we can think of the following (all correct) ways of
guaranteeing no run-time surprise upon failed assignment in the case of
nasty types:

- double buffer with second buffer on the heap (spatial optimization, in
case assignments are rare)
- double buffer with second buffer inside variant (predictable time
guarantee)
- fail to compile the assignment (no spacial cost is payed for users that
use functional-programming style)

Either of these choices is correct and may be considered best for a given
group of people.

By this, I do not mean that adding policies is necessarily a good way to
go. Having many types that do almost the same thing (whether they are
instantiated from templates or defined manually) is a problem in itself.

Regards,
&rzej;