Gennadiy Rozental wrote:
> > > 2. Top level const requirement on bounded types.
> > > It's unreasonable. I should be able to define variant with const
> > > types. It will be as usable as usual constant types are. The only
> > > requirements that we may incur is that if one types is const,
> > > rest should be also.
> >
> > It's actually not unreasonable: one of the primary goals of variant is
> > to match the semantics of its bounded types as closely as possible. The
> > prohibition on top-level const types, then, is quite reasonable.
> >
> > To see, consider the following:
> >
> > const int i = 3;
> > i = 4; // error
> >
> > variant<const int> v;
> > v = 4; // error?
> >
> > If top-level const types *were* allowed, then the assignment would
> > succeed. Itay and I decided such was highly undesirable. Let me know if
> > you disagree with the above reasoning.
>
> If I understood you properly you having problem with the following code
> successful compilation:
>
> template<typename T>
> struct A
> {
> char buf[4];
>
> template<typename Arg>
> void
> operator=( Arg const& arg )
> {
> new (buf) T(arg);
> }
> };
>
> int main() {
> A<const int> a;
>
> a = 4;
> }
>
> This wouldn't happened if you use reinterpret cast based implementation,
but
> probably do not want to rely on it. What I would do is to explicitly
> prohibit some operations using static asserts for top level const type
> situation. It wouldn't cost you anything and allow to support this usage
> case.
I think you misunderstand: What I'm arguing is that the "usage case" you
propose here is itself erroneous. This is *not* an issue of whether I can
implement the behavior. (In fact, I need to do additional work to prohibit
it.)
Let me know if you still disagree.
Thanks,
Eric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
