220 5816 <dd70eb3b-8529-42ca-9f79-3bec4ccdcbd1@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: Making std::vector<std::unique_ptr<void>> not be
 copy constructible, among other things
Date: Sun, 25 Aug 2013 20:44:52 -0700 (PDT)
Lines: 99
Approved: news@gmane.org
Message-ID: <dd70eb3b-8529-42ca-9f79-3bec4ccdcbd1@isocpp.org>
References: <CAEn_SP+=gQwxB8RY6ZY6EDHD+gATtzYX_mrKwRZQDEcBcuO+ZQ@mail.gmail.com>
 <079a64f7-2606-4309-8472-8624032c2f03@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_109_4304604.1377488692779"
X-Trace: ger.gmane.org 1377488692 21848 80.91.229.3 (26 Aug 2013 03:44:52 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Mon, 26 Aug 2013 03:44:52 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBNU65OIAKGQE2XYDRJI@isocpp.org Mon Aug 26 05:44:56 2013
Return-path: <std-proposals+bncBCEKFTV6ZUMBBNU65OIAKGQE2XYDRJI@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ie0-f200.google.com ([209.85.223.200])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBNU65OIAKGQE2XYDRJI@isocpp.org>)
	id 1VDnjb-0002Gw-Ei
	for gclcip-std-proposals@m.gmane.org; Mon, 26 Aug 2013 05:44:55 +0200
Original-Received: by mail-ie0-f200.google.com with SMTP id c10sf11393369ieb.7
        for <gclcip-std-proposals@m.gmane.org>; Sun, 25 Aug 2013 20:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:message-id:in-reply-to:references:subject:mime-version
         :x-original-sender:reply-to:precedence:mailing-list:list-id
         :list-post:list-help:list-archive:list-subscribe:list-unsubscribe
         :content-type;
        bh=Xa/+RwRn/jiFyvv4zV6nvkZEt2hwtfy+Cdk+nyhONMs=;
        b=HRQIPckzS1f/r9H+m8J3YHJQTEgZ37PkWjVGVGYiZ82VfoUmSMHcAFWEhVJJVowKVC
         VED3jwdKUt8NrenRUmSm4eNTjhpcyZy/TwPZ/nUvvHpT/O14FduvEJ6oi62WsLBK8aaE
         1N++UakEqeh2RoyzSLgex0xAnrJ1WFJdIQmycLs+WN+sdh1xcKTN0vwfXkF4haNDl1i3
         Bc60AAXWG3nPdxPPfzap1/X6W8PXU0Vf8Vge7fRQBpbtXLKeC5FrAEDn9F/yctgJ0g+K
         otnrBup1Lsl7q81Ar5TOdwYCGmmW4nAFsWEewZTTCjjlSd4G8G+NrZfNFbv9Ai8fqZFu
         xgqw==
X-Received: by 10.42.137.1 with SMTP id w1mr6617905ict.8.1377488694331;
        Sun, 25 Aug 2013 20:44:54 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.115.36 with SMTP id jl4ls2165719igb.33.canary; Sun, 25 Aug
 2013 20:44:53 -0700 (PDT)
X-Received: by 10.50.62.20 with SMTP id u20mr245184igr.11.1377488693912;
        Sun, 25 Aug 2013 20:44:53 -0700 (PDT)
In-Reply-To: <079a64f7-2606-4309-8472-8624032c2f03@isocpp.org>
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>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5816
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/5816>

------=_Part_109_4304604.1377488692779
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, August 25, 2013 10:54:17 AM UTC-7, David Krauss wrote:
>
> The problem here is simply a library bug, be it the Standard Library or 
> other. A constructor shouldn't be declared with no available definition. 
> Some other places already state "this signature does not participate in 
> overload resolution..." and the principle needs more general application.
>
> If a library defect hasn't been filed, that's the next order of business, 
> but this may require a paper, too. The fix could be just adding a sentence 
> to the container requirements table.
>
> Concepts simplify introspection a la wellformed() (it's called requires()) 
> but it still only applies to immediate context. You don't want the overhead 
> of instantiating a definition during overload resolution, of a function 
> that might never be used.
>
But no such definition is being instantiated. That's *the point*. It sees 
that there's a function with a compatible signature, but that function has 
a requires clause. So it evaluates the requires clause, and if everything 
checks out, *then* it may go on and use that function. But nothing gets 
instantiated unless the requires checks out.
 

> Implementing SFINAE on a copy constructor is unfortunately harder than it 
> should be, and I'm not aware of any fix in the pipeline. Two lightweight 
> alternatives:
>
> 1. Implement the constructor in a base, and inherit from another base 
> which is conditionally copy-constructible, so the implicit definition of 
> the derived constructor is conditionally deleted. 
>
2. Use std::conditional to replace the constructor parameter type with a 
> harmless, unused tag.
>
And what happens if you instantiate std::vector with values of this 
"harmless, unused tag" type? 

-- 

--- 
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/.

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

<div dir=3D"ltr">On Sunday, August 25, 2013 10:54:17 AM UTC-7, David Krauss=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The problem here is sim=
ply a library bug, be it the Standard Library or other. A constructor shoul=
dn't be declared with no available definition. Some other places already st=
ate "this signature does not participate in overload resolution..." and the=
 principle needs more general application.<p>If a library defect hasn't bee=
n filed, that's the next order of business, but this may require a paper, t=
oo. The fix could be just adding a sentence to the container requirements t=
able.</p><p>Concepts simplify introspection a la wellformed() (it's called =
requires()) but it still only applies to immediate context. You don't want =
the overhead of instantiating a definition during overload resolution, of a=
 function that might never be used.<br></p></blockquote><div>But no such de=
finition is being instantiated. That's <i>the point</i>. It sees that there=
's a function with a compatible signature, but that function has a requires=
 clause. So it evaluates the requires clause, and if everything checks out,=
 <i>then</i> it may go on and use that function. But nothing gets instantia=
ted unless the requires checks out.<br>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><p>Implementing SFINAE on a copy constructor is unfort=
unately harder than it should be, and I'm not aware of any fix in the pipel=
ine. Two lightweight alternatives:</p><p>1. Implement the constructor in a =
base, and inherit from another base which is conditionally copy-constructib=
le, so the implicit definition of the derived constructor is conditionally =
deleted.&nbsp;</p></blockquote><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><p>2. Use std::conditional to replace the constructor parameter type with =
a harmless, unused tag.<br></p></blockquote><div>And what happens if you in=
stantiate std::vector with values of this "harmless, unused tag" type? <br>=
</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_109_4304604.1377488692779--

.