Return-Path: 
 <dev-return-8137-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 23106 invoked from network); 8 Jul 2008 20:38:34 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 8 Jul 2008 20:38:34 -0000
Received: (qmail 40408 invoked by uid 500); 8 Jul 2008 20:38:35 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 40342 invoked by uid 500); 8 Jul 2008 20:38:35 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 40331 invoked by uid 99); 8 Jul 2008 20:38:35 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jul 2008 13:38:35 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Jul 2008 20:37:44 +0000
Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com
 [10.22.129.22])
	by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m68Ka5VM020866
	for <dev@stdcxx.apache.org>; Tue, 8 Jul 2008 20:36:05 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Another potential hole in the tuple specs
Date: Tue, 8 Jul 2008 14:36:10 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FC1A@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Another potential hole in the tuple specs
Thread-Index: AcjhGzyAz5sj3mJwTBCcrhY9Bk7U7wADWbSwAAOxvrA=
References: <4872AA41.7040005@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0634@exchmail01.Blue.Roguewave.Com>
 <48739B25.5060406@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0635@exchmail01.Blue.Roguewave.Com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

Eric Lemings wrote:
>
>> Martin Sebor wrote:
>>=20
>> Eric Lemings wrote:
>> > =20
>> [...]
>> > A const assignment operator?  Sounds unorthodox but I'll=20
>> > try it out.
>> >=20
>> > 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.
>>=20
>> 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=20
>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 could agree that it shouldn't _need_ to be const given that it needs
no member data and it is just a placeholder type. But I'd be willing to
bet that this was an intentional design decision.

>
>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 following testcase works just fine (on acc-6.16, gcc-4.3.1 &
msvc-8.0)

  namespace std {


  struct _Ignore
  {
      template <class _TypeT>
      void operator=3D(const _TypeT&) const
      {
      }
  };

  // should make this extern and define in a .cpp
  const _Ignore ignore =3D std::_Ignore ();


  } // namespace std



  int main ()
  {
      std::ignore =3D 1;
      std::ignore =3D 1.f;

      std::ignore =3D std::ignore;
      std::ignore =3D (void (*)(int))0;

      return 0;
  }

Perhaps you could post the error and a testcase?

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

I'm sure the above strategy will work.

>
>Brad.
>