[boost] Re: Re: Variant Library: top level const types

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-04-07 20:31:59

> > Did I correctly understand the reason why you think you could not
prevent
> above assignment?
> >
> > If yes, my proposition is to put following code in the assignment
operator
> > (and all other mutating operators like copy assignment above):
> >
> > BOOST_STATIC_ASSERT( !boost::is_const<T>::value );
> >
> > That should prevent user from trying to use assignment operators for the
> > variant parameterized with const types.
>
> First I want to make clear that my objection to your proposal has
absolutely
> nothing to do with any *technical* difficulties.

That's great. Cause you keep repeating that you could not prevent
assignment. My point from the technical stand-point: you could.

> Rather, I argue your proposal is logically incoherent. You propose that
> variant may be defined with const types. For example,
>
>   variant<int const, std::string const>
>
> I do not see how the semantics of such a type might reasonably differ in
any
> way whatsoever from the following "natural" syntax:
>
>   variant<int, std::string> const
>
> Peter Dimov noted this as well
> (http://aspn.activestate.com/ASPN/Mail/Message/1594864). Further, I'm not
> sure why you would *want* such semantics.

That's an excellent point made by Peter. That is why I sad that there is a
"workaround" and I feel much more relaxed now. In the same reply to Peter I
also made a point that there is one case when above solutions does differ.
The difference is that in second case one need to type word const
explicitly. What does that mean? That means that if one is using
boost::variant in generic programming as member of other solution, absence
of const support enforce similar limitation to the whole solution.

> The other suggestion I think your proposal contains is to give meaning to
> the case where not every parameterized types is const. For example,

No. I never made such proposition. Moreover in original review I explicitly
sad that if one type is const you should enforce that the rest are also.

> Correct me if I've erred, but IMO this thread is getting old.

I propose you either:
1. Does add support for const types,
2. Does not add support for const types and document how const variant could
be implemented in specific case. User willing to use variant in generic
solution will need to select 'variant'/'variant const' himself.

Gennadiy