incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: Another potential hole in the tuple specs
Date Tue, 08 Jul 2008 18:46:51 GMT
 

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Tuesday, July 08, 2008 10:52 AM
> To: dev@stdcxx.apache.org
> Subject: Re: Another potential hole in the tuple specs
> 
> Eric Lemings wrote:
> >  
> [...]
> > A const assignment operator?  Sounds unorthodox but I'll try it out.
> > 
> > My current workaround is to declare std::ignore mutable (i.e.
> > non-const).  A const assignment operator (if it works) would be
> > preferable; no visible workaround required.
> 
> Remember that even the absence (or presence) of the const
> qualifier on things like std::ignore can be detected by
> conformance test suites so dropping it is not a viable
> option.

Assuming the draft standard is actually correct, that is.  In this case,
I don't think there is any real need for std::ignore to be a constant
really.  (Thinking about asking whether std::ignore really needs to be a
constant on the committee reflector.)

I tried making std::ignore const and adding const to the internal
assignment operator.  I also tried adding overloads for const and
non-const assignment.  Still got errors in all cases.

The only other recourse I can think of is to use remove_const on the
element types where appropriate.

Brad.

Mime
View raw message