Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Neil Groves (neil_at_[hidden])
Date: 2013-01-25 09:58:18

On Fri, Jan 25, 2013 at 2:32 PM, Dave Abrahams <dave_at_[hidden]> wrote:

>
> on Mon Jan 21 2013, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
>
> > On Monday 21 January 2013 19:06:32 Paul Smith wrote:
> >> On Mon, Jan 21, 2013 at 6:12 PM, Joel de Guzman <djowel_at_[hidden]>
> wrote:
> >> > This notion of a "valid" state
> >> > is not clear to begin with anyway and many say it depends on the
> library
> >> > to define what "valid" means. The case of NaN is a very clear example
> >> > of a perfectly "valid" state similar to what we have here.
> >>
> >> I'm not sure what the NaN example supposed to convey? I think Nevin
> >> brought it up to show that std::less<double> is not a weak partial
> >> order. And guess what, it technically isn't! Try to put NaNs inside an
> >> associative container and watch the world collapse. The big difference
> >> is that no operation on non-NaNs that the container performs ever
> >> produces a NaN out of thin air.
> >
> > Why would a container try to order moved-from elements?
>
> Moved-from elements can be left there due to exceptions propagating out
> of the code.  That's a *new* state that wasn't allowed before
> move-enabling, so if these moved-from elements have a state outside the
> former invariants, it will break some code.
>
>
Isn't leaving the class with it's invariants broken simply a defect? From
my perspective the class invariants are defined such that the elements are
stored and order is maintained. This is such a core class-invariant for the
containers under discussion that it seems absurd to consider breaking it.
It isn't merely a matter of compatibility, it is a matter of design
coherence.

The NaN example is explainable by using Design by Contract too. The
pre-conditions of the associative container operations are such that the
key must not be NaN. Hence the class invariants are maintained and the
world is full of unicorns and rainbows. However once NaNs are input, the
class invariants are not maintained. This is entirely reasonable.

> --
> Dave Abrahams
> BoostPro Computing                  Software Development        Training
> http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost
>

My vote is that we shouldn't even consider allowing the class invariants
for ordered containers to be broken. I cannot imagine a motivation for
allowing them to be broken. I suspect this may be a symptom of my failure
to comprehend part of this discussion.

Neil Groves