wt., 16 kwi 2019 o 22:02 Robert Ramey via Boost
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@lists.boost.org> 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;