Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-09 21:51:09

--- Eric Friedman <ebf_at_[hidden]> wrote:
> brock wrote:
> [snip]
> > There are a lot of disadvantages in allowing variants to be singular at any
> > time. We've been all over this. But if we say they can be singular only
> > after a failed assignment, then you can pretty safely ignore the possibility
> > in most of your code... I think. I wonder what Eric and Dave think of this
> > or if they finally got tired of all the noise and tuned out :) Maybe this
> > is noise too :)
> I've suggested it before.
> See
> From an implementation standpoint, there is no problem at all with
> singular variants; I can code variant so that it destroys itself
> properly even when in a singular state. As well, since assignment to a
> singular variant is a meaningful operation, it is possible to "restore"
> a singular variant to full-status. However, visitation of a singular
> variant is *not* a meaningful operation in anyway and should be left
> undefined.
> Given that singular variants will *only occur in the wake of failed
> assignment*, this may not be a problem. Allowing the possibility of
> singular variants at all, however, does represent a departure from where
> variant has been in the past. Before I make a change like this, I would
> appreciate some sort of consent from the community. So far, this has
> been significantly lacking.

You know *my* point of view and rationale.
I am strongly for singular variant for now.
The better option is strong guarantees
but the discussion about it is still underway.

Thanks again for the last changes!


Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

Boost list run by bdawes at, gregod at, cpdaniel at, john at