220 4709 article Path: news.gmane.org!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Remove vector? Date: Wed, 29 May 2013 12:51:42 -0500 Lines: 125 Approved: news@gmane.org Message-ID: References: <83a68179-f8cd-42e9-a880-2bd797b30c28@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2b55c343cfb04dddf0be8 X-Trace: ger.gmane.org 1369849948 25579 80.91.229.3 (29 May 2013 17:52:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 May 2013 17:52:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCE35H5S6IDBBV4ATGGQKGQE2N5OXHQ@isocpp.org Wed May 29 19:52:28 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f69.google.com ([209.85.212.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UhkXw-0001eV-Il for gclcip-std-proposals@m.gmane.org; Wed, 29 May 2013 19:52:24 +0200 Original-Received: by mail-vb0-f69.google.com with SMTP id p13sf8886021vbe.8 for ; Wed, 29 May 2013 10:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:sender:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=q83XxqPyhpA/DJhQ4dIX0DBbmGlXeB+NWBKDdhNi/mQ=; b=LxuHdJKy883hqt8EfLXN5EcBDraUROQhlL9yJnowK2bUM0LGiQPOUjcJ1xPHx1JzIx gfbw90E/nPs5wwjZ4tsHpo+mITP/xWDwOlgSyElLQxr6R7PeHmykDDLPE3m3YVom3vWR KTKjzIdre99TXaulJINsVUyoS2Mu/jtZtVXaNfN3Wm/xTWXXuVKV2q0idzNmbMgo5VV5 WjB/+rkfwbViK1J+pUpKO7ST0YtV8Y2/g8TbvdmdI+XdCA0GtyyAC/+eUz4KNBtb+o/I VJ2n4oEa2gSLIRt/zHWI6Y1sCOvpif2sX0fEShiLVI6s1+mR8Cv4VFKDWsKR1k7b7WY7 ODtQ== X-Received: by 10.236.87.79 with SMTP id x55mr1949128yhe.54.1369849943696; Wed, 29 May 2013 10:52:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.24.16 with SMTP id q16ls3944166qef.46.gmail; Wed, 29 May 2013 10:52:22 -0700 (PDT) X-Received: by 10.229.175.202 with SMTP id bb10mr1341818qcb.136.1369849942538; Wed, 29 May 2013 10:52:22 -0700 (PDT) Original-Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by mx.google.com with ESMTPS id p9si13420010qcx.152.2013.05.29.10.52.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 10:52:22 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 209.85.128.46 as permitted sender) client-ip=209.85.128.46; Original-Received: by mail-qe0-f46.google.com with SMTP id 1so5106199qee.5 for ; Wed, 29 May 2013 10:52:22 -0700 (PDT) X-Received: by 10.224.65.72 with SMTP id h8mr4154495qai.73.1369849942259; Wed, 29 May 2013 10:52:22 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.49.64.165 with HTTP; Wed, 29 May 2013 10:51:42 -0700 (PDT) In-Reply-To: <83a68179-f8cd-42e9-a880-2bd797b30c28@isocpp.org> X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.128.46 as permitted sender) smtp.mail=nliber@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4709 Archived-At: --001a11c2b55c343cfb04dddf0be8 Content-Type: text/plain; charset=ISO-8859-1 On 29 May 2013 12:42, Nicol Bolas wrote: > > http://www.gotw.ca/publications/N1185.pdf >> >> But it's not adopted. >> >> Anyway, vector sucks, and we know it. How about to entirely >> remove it? >> > > > > We simply add another specialization to `vector` called > "vector". If you create a `vector` with the > `std::real_bool` type, then you get exactly what you would have gotten if > `vector` weren't a specialization: an actual `vector` that contains > actual `bool`s. The `value_type` of `vector` would be > `bool`, and so forth. > > We don't have to get rid of `vector` to get what we want. We just > have to call it something else. And since this `std::real_bool` type can't > be used in existing code (defining new things in the `std` namespace is > undefined behavior), it can't conflict with anything now. > > The downside is that a template function that takes a `vector`, where > `T` is some type, may assume that `T` is the `value_type` of the `vector`, > which it would not be in the case of `std::real_bool`. > -1. The primary argument (so far) for removing the vector specialization is uniformity with the rest of vector. As you point out, your solution still doesn't achieve it. While the standard strives for high levels of backwards compatibility, it need not be 100% (heck, C++11 vector is not 100% backwards compatible with C++03 vector), and we shouldn't be adding more warts. The standard is the right place to fix this, and we should fix it and not just put a band aid on it. -- Nevin ":-)" Liber (847) 691-1404 -- --- 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. --001a11c2b55c343cfb04dddf0be8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29 May 2013 12:42, Nicol Bolas <jmckesson@gmail.com> wr= ote:

=A0 http://www= ..gotw.ca/publications/N1185.pdf

But it's not adopted.

Anyway, vector<bool> sucks, and we know it. =A0How about to entir= ely
remove it?

We simply add another specializatio= n to `vector` called "vector<std::real_bool, Allocator>". I= f you create a `vector` with the `std::real_bool` type, then you get exactl= y what you would have gotten if `vector<bool>` weren't a speciali= zation: an actual `vector` that contains actual `bool`s. The `value_type` o= f `vector<std::real_bool>` would be `bool`, and so forth.

We don't have to get rid of `vector<bool>` to get what we wan= t. We just have to call it something else. And since this `std::real_bool` = type can't be used in existing code (defining new things in the `std` n= amespace is undefined behavior), it can't conflict with anything now.
The downside is that a template function that takes a `vector<T>`= , where `T` is some type, may assume that `T` is the `value_type` of the `v= ector`, which it would not be in the case of `std::real_bool`.

-1.

The primary argument (so far) for removing= the vector<bool> specialization is uniformity with the rest of vecto= r.=A0 As you point out, your solution still doesn't achieve it.

While the standard strives for high levels of backwards compatibility, it n= eed not be 100% (heck, C++11 vector is not 100% backwards compatible with C= ++03 vector), and we shouldn't be adding more warts.=A0 The standard is= the right place to fix this, and we should fix it and not just put a band = aid on it.

--
=A0Nevin ":-)" Liber=A0 <mailto:nevin@eviloverlord.com= >=A0 (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail 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-pro= posals/?hl=3Den.

--001a11c2b55c343cfb04dddf0be8-- .