220 4689 <2baa70a2-bad8-4b78-98de-3585bb47f2df@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Nicol Bolas <jmckesson@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Remove vector<bool>?
Date: Tue, 28 May 2013 15:31:06 -0700 (PDT)
Lines: 115
Approved: news@gmane.org
Message-ID: <2baa70a2-bad8-4b78-98de-3585bb47f2df@isocpp.org>
References: <CAGsORuDQdeWAO5yjA6=h0hW9Y0Sj4F1gcHB61udw5JFmtx+g4Q@mail.gmail.com>
 <CAGg_6+O9XJucMxwEhU+50Dzx0Tz7XRK0cWyrkUHuPSoEz9TqEw@mail.gmail.com>
 <e59c2a57-6068-4098-8667-5d086b2961fd@isocpp.org> <7371f4b8-8c47-4f17-af1e-902a5c8b17e4@isocpp.org>
 <CAGg_6+NAu8=MvJQaRK3_tVJ3ZpUx_=q4iY_8aPL8mjkyFZOgDA@mail.gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_4216_19179901.1369780266502"
X-Trace: ger.gmane.org 1369780270 29374 80.91.229.3 (28 May 2013 22:31:10 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 28 May 2013 22:31:10 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLHASSGQKGQERIXBKBQ@isocpp.org Wed May 29 00:31:10 2013
Return-path: <std-proposals+bncBCEKFTV6ZUMBBLHASSGQKGQERIXBKBQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ie0-f199.google.com ([209.85.223.199])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBLHASSGQKGQERIXBKBQ@isocpp.org>)
	id 1UhSQA-0002RJ-4N
	for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 00:31:10 +0200
Original-Received: by mail-ie0-f199.google.com with SMTP id 9sf9331512iec.10
        for <gclcip-std-proposals@m.gmane.org>; Tue, 28 May 2013 15:31:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject
         :mime-version:x-original-sender:reply-to:precedence:mailing-list
         :list-id:x-google-group-id:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe:content-type;
        bh=f4fuDIUMr3TzfeyHSEH5sYEeEjr8u91fMDtdofvkbBo=;
        b=B3PqumlLOzfJm6mkeThfEy+3naYPnogTzKqZVwJvbVu6W3Y22XbTpWXsZqFgcFS499
         1x7N/EM4FWFeO7YVMfRqcIrd3bAUwKzmWrKcP5RFuxQrLQdnigt3Y+UmzxwSqC/1wnSh
         prR9HM2MQHXgXb+JMX9h46E8MnBXabm6B5Ac7rZK/xacF3kg+Q6lhKFjpsadqYxQLamH
         liXQA4d9a9h6eP3mBG/wf2/pmp2OKtiU22i4TbPPe5MWI8W/8aTaOuQTtUbzHGHjM3jb
         X8gqA1GuWW3WJaOQMKaSqiUwMdfMHWNMTShrzEO7BtRTiGbxlMos8PSbMqpQT02k7K59
         ZTjQ==
X-Received: by 10.50.11.50 with SMTP id n18mr16735776igb.0.1369780268900;
        Tue, 28 May 2013 15:31:08 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.61.204 with SMTP id s12ls2920982igr.30.gmail; Tue, 28 May
 2013 15:31:07 -0700 (PDT)
X-Received: by 10.50.101.39 with SMTP id fd7mr1853471igb.16.1369780267911;
        Tue, 28 May 2013 15:31:07 -0700 (PDT)
In-Reply-To: <CAGg_6+NAu8=MvJQaRK3_tVJ3ZpUx_=q4iY_8aPL8mjkyFZOgDA@mail.gmail.com>
X-Original-Sender: jmckesson@gmail.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post?hl=en>,
 <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?hl=en&topic=25838>,
 <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4689
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/4689>

------=_Part_4216_19179901.1369780266502
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, May 28, 2013 1:12:59 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 28 May 2013 15:00, Nicol Bolas <jmck...@gmail.com <javascript:>> wrote:
>
>>
>> Personally, I agree with Howard; we should add a class that has all of 
>> this functionality (presumably with some degree of required sizing) that 
>> would be a drop-in replacement for those who need the sizing features of 
>> vector<bool>. But the question remains: even with a drop-in replacement, 
>> how much code will be *broken* because of this?
>>
>
> There is never any real way to know, but it's been around a long time
>
> The problems with just pulling it are:
>
> 1.  Silent changes really annoy users.
> 2.  It makes migration harder, as you are required to change your code in 
> a backwards-incompatible way just to get it working under C++17.
>
> For C++17 I think we can deprecate the vector<bool> specialization at the 
> same time (in favor of no specialization for the subsequent release), but I 
> don't see just removing it as something that has any chance of passing the 
> committee.


This isn't like the auto_ptr->unique_ptr thing; there, the idea there was 
to get people using a new class with a new interface and new behavior (as 
an aside, I see no point in removing auto_ptr; it does no harm sitting 
there, since everyone already knows to use unique_ptr where available).

The point of this exercise is not to get a class that does exactly what 
`vector<bool>` does. The point of this exercise is to be able to actually 
create a real, legitimate `vector` that contains actual `bool`s. Getting 
users of `vector<bool>` to use a new class is merely the *means* to that 
end.

So a plan that could, *maybe* get us back `vector<bool>` around 2020 isn't 
particularly useful. I would much rather find a plan that gets us back 
`vector<bool>` in fewer than 3 standard revisions.

-- 

--- 
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_4216_19179901.1369780266502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, May 28, 2013 1:12:59 PM UTC-7, Nevin ":-)" Liber wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On 28 May 2013 15:00, Nicol Bo=
las <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"mVXkqKDqWWoJ">jmck...@gmail.com</a>&gt;</span> wrote:<br>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><div>Personally, I agree with Howard; we should add a class that has al=
l of this functionality (presumably with some degree of required sizing) th=
at would be a drop-in replacement for those who need the sizing features of=
 vector&lt;bool&gt;. But the question remains: even with a drop-in replacem=
ent, how much code will be <i>broken</i> because of this?<br clear=3D"all">

</div></blockquote><div><br>There is never any real way to know, but it's b=
een around a long time<br><br>The problems with just pulling it are:<br><br=
>1.&nbsp; Silent changes really annoy users.<br>2.&nbsp; It makes migration=
 harder, as you are required to change your code in a backwards-incompatibl=
e way just to get it working under C++17.<br>

<br></div></div>For C++17 I think we can deprecate the vector&lt;bool&gt; s=
pecialization at the same time (in favor of no specialization for the subse=
quent release), but I don't see just removing it as something that has any =
chance of passing the committee.</blockquote><div><br>This isn't like the a=
uto_ptr-&gt;unique_ptr thing; there, the idea there
 was to get people using a new class with a new interface and new=20
behavior (as an aside, I see no point in removing auto_ptr; it does no harm=
 sitting there, since everyone already knows to use unique_ptr where availa=
ble).<br><br>The point of this exercise is not to get a class that does exa=
ctly what `vector&lt;bool&gt;` does. The point of this exercise is to be ab=
le to actually create a real, legitimate `vector` that contains actual `boo=
l`s. Getting users of `vector&lt;bool&gt;` to use a new class is merely the=
 <i>means</i> to that end.<br><br>So a plan that could, <i>maybe</i> get us=
 back `vector&lt;bool&gt;` around 2020 isn't particularly useful. I would m=
uch rather find a plan that gets us back `vector&lt;bool&gt;` in fewer than=
 3 standard revisions.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4216_19179901.1369780266502--

.