Return-Path: 
 <dev-return-8129-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: (qmail 36414 invoked from network); 8 Jul 2008 00:30:04 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 8 Jul 2008 00:30:04 -0000
Received: (qmail 40447 invoked by uid 500); 8 Jul 2008 00:30:05 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 40431 invoked by uid 500); 8 Jul 2008 00:30:05 -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 40420 invoked by uid 99); 8 Jul 2008 00:30:05 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2008 17:30:05 -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 00:29:14 +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 m680RYoQ015992
	for <dev@stdcxx.apache.org>; Tue, 8 Jul 2008 00:27:34 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: Mon, 7 Jul 2008 18:27:40 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0634@exchmail01.Blue.Roguewave.Com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Another potential hole in the tuple specs
Thread-Index: Acjgi6I4wfiTpwGPSOCmrg/dvUovEwAAytgA
References: <4872AA41.7040005@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

=20

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Monday, July 07, 2008 5:44 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Another potential hole in the tuple specs
>=20
> Eric Lemings wrote:
> > =20
> >=20
> > Here's another potential problem with the tuple spec.  The=20
> latest draft
> > declares std::ignore like so:
> > =20
> > 	namespace std {
> > 	    const /*unspecified*/ ignore;
> > 	}
> > =20
> > The type of std::ignore is implementation-defined but for=20
> illustration,
> > let's say its defined like this:
> >=20
> > 	namespace std {
> >=20
> > 	struct _Ignore
> > 	{
> > 	    template <class _Type>
> > 	    _Ignore& operator=3D (const _Type& value) { return *this; }
> > 	};
> >=20
> > 	const _Ignore ignore =3D _Ignore ();
> >=20
> > 	} // namespace std
> >=20
> > (The need for the operator will become evident shortly.)
> >=20
> > Here's how the tie() function is specified, quoting from=20
> the standard:
> >=20
> > 	  template<class... Types}
> > 	  tuple<Types&...> tie(Types&... t);
> >=20
> > 	4 Returns: tuple<Types&>(t...). When an argument in t is ignore,
> > assigning any value to the corresponding
> > 	  tuple element has no effect.
> >=20
> > 	5 [ Example: tie functions allow one to create tuples that
> > unpack tuples into variables. ignore can be used for
> > 	    elements that are not needed:
> >=20
> > 		int i; std::string s;
> > 		tie(i, ignore, s) =3D make_tuple(42, 3.14, "C++");
> > 		// i =3D=3D 42, s =3D=3D "C++"
> >=20
> > 	  -end example ]
> >=20
> > In the example, the return type of the call to the tie() function is
> > std::tuple<int&, const std::_Ignore&, std::string&>.  Note that the
> > second element type in the tuple is a constant reference. =20
> Regardless of
> > the implementation-defined type of std::ignore, isn't it=20
> impossible to
> > change the value of a constant reference once initialized? =20
> This would
> > mean the example shown above is ill-formed I believe.
>=20
> You mean because tie(i, ignore, s) =3D make_tuple(42, 3.14, "C++")
> must assign 3.14 to std::ignore? Would declaring the assignment
> operator cost be a way to make it work?

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.

Brad.