220 29545 <2adcd4e7-8711-4a6c-b5b6-8ea910e8b8bc@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Perfectly forwarding initializer_list, in cases other than any/optional/variant Date: Sun, 27 Nov 2016 01:33:38 -0800 (PST) Lines: 196 Approved: news@gmane.org Message-ID: <2adcd4e7-8711-4a6c-b5b6-8ea910e8b8bc@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_187_1080890751.1480239218659" X-Trace: blaine.gmane.org 1480239222 20251 195.159.176.226 (27 Nov 2016 09:33:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 27 Nov 2016 09:33:42 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIPHUHKYECRUBFCMJ3L2@isocpp.org Sun Nov 27 10:33:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cAvq4-0004YB-Pa for gclcip-std-proposals@m.gmane.org; Sun, 27 Nov 2016 10:33:37 +0100 Original-Received: by mail-pg0-f71.google.com with SMTP id f188sf284248729pgc.1 for ; Sun, 27 Nov 2016 01:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=UykKtkbe/oRD5qTh2dHWJjImvS5QHA6rVtS8XkwZLfo=; b=Wk58WPS8KjyHKfRlV9V5dR9o8stdDQePJ01DeUqnVytG3PYfpAAvgrvobJMIMnBL9y nTSLQ+W3K0645Lje9to6sgZnEHQjQ6YLUdND+GX6CeBRXs/Ngg/Up+6IvBu9Ps+xS8E1 Mc2Sk8u64aL4GiQcZCPyXHGHBPKr+Gjqeq6OcKeVJ/O2ugYQto3SLgSRaVcRbA7tey/I 7iwuwWn3S2jYfFtfbB2ewTZEFDg6UBO3ZZsRofPh/YIj6GVztpWuY8AfQEt34mdTY9JB xzn20R7BfDoKzEp8skNSCJReM7ehwx5oDM5blvJYfOcuAwhamSCQ72C3DwkA8EkdoSJQ jxGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=UykKtkbe/oRD5qTh2dHWJjImvS5QHA6rVtS8XkwZLfo=; b=H4YUMRqMKkj0UbAbq6BBM1JpQXqe4bWFQMi1/wLOEHRBXDRyoqTZKGQKX8P5vls/zZ Xnoy9L+fB+GcmdTg/jOFJc7ThcAin7jtiQ+uwFeBqa0eyvKtnpPyRBvDn6M73SSCM2K7 FhwGp/nng9DGsbilSMECgAWQlk/cC7LjD6/0Otn69GfARKKm7XoVSexlNlGL0wvojrDS EqDIOOisp7OIqFv/LnCWM2E5D7qdyGcyADWvCQQcF8f72tt5lwYv/U9u1oEgyXv/2kSm RYj0aY2PA+EoMPGfV18/m9W2CXQM3I5KWnswlGgRL/VFQpmjoFdX0MlCYK7mufQzBzcZ k0BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=UykKtkbe/oRD5qTh2dHWJjImvS5QHA6rVtS8XkwZLfo=; b=Ek9pOIWEThpbfW4aqyBkbbBAhdL/UMxoQ4MBPW3Kwt6WPlkv2Ss67fflOD3NJ5o1ls HQ9f0kBkNjMCFhVF9/GldYl8lVnCNQPU9cJnjLUr557dddWP+RjHbsqqCmFshYXYg6Xz ajxqzQcvxS6s+2gkUDSn3rCoLtnKkEUcpRZK4qijuKL7DV3O03NhICblt8pcdcYD77oD dXZcGU8Y3eu/3BcsLUcg7fj/A5bbismAaODv+LsiC0PW5NyV9fONzxRnZ2cB5eUnLJiH G7q051mBZOkkVHwm7T+OneOwd6gADQpS1I2/jG2Z8lBEFducicXV9FwGtSyk8lznKadR ifxA== X-Gm-Message-State: AKaTC03N//c8619XwWh7uBOHM7dMctGxZNLFQEpVVYmlIhb/5VN0l+hv2Tc/DmRdQmzjnw== X-Received: by 10.99.45.130 with SMTP id t124mr7393027pgt.64.1480239220152; Sun, 27 Nov 2016 01:33:40 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.32.170 with SMTP id x39ls7959965ota.23.gmail; Sun, 27 Nov 2016 01:33:39 -0800 (PST) X-Received: by 10.157.4.119 with SMTP id 110mr401798otc.11.1480239219184; Sun, 27 Nov 2016 01:33:39 -0800 (PST) X-Original-Sender: arthur.j.odwyer@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:29545 Archived-At: ------=_Part_187_1080890751.1480239218659 Content-Type: multipart/alternative; boundary="----=_Part_188_594114577.1480239218659" ------=_Part_188_594114577.1480239218659 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Now that std::any, std::optional, and std::variant have blessed the idea of= =20 splitting each "perfectly forwarding emplacement function" into a pair of= =20 functions, one taking initializer_list and the other not, I wonder if=20 there's any significant interest in retrofitting that solution onto the=20 rest of the STL containers. For example, to take this current wording in [forwardlist.modifiers] template reference emplace_front(Args&&... args); Effects: Inserts an object of type value_type constructed with value_type(s= td::forward(=20 args)...) at the beginning of the list.=20 and replace it with this wording instead: template reference emplace_front(Args&&... args); Effects: Inserts an object of type value_type constructed with value_type(s= td::forward(=20 args)...) at the beginning of the list.=20 Remarks: This function shall not participate in overload resolution unless = is_constructible_v is true. template reference emplace_front(initializer_list<= U> il, Args&&... args); Effects: Inserts an object of type value_type constructed with value_type(i= l,=20 std::forward( args)...) at the beginning of the list.=20 Remarks: This function shall not participate in overload resolution unless = is_constructible_v&, Args...> is true. and so on for std::vector, std::list, std::deque,... Is there a technical reason this retrofitting hasn't happened, or is it=20 just one of those "nobody's written the paper yet" cases? Ville's N4462=20 seems= =20 to be a discussion of the "how to forward initializer_list" problem in=20 general, but AFAICT it dates from before the adoption of the two-function= =20 approach. I don't know where the two-function approach originally came from= =20 =E2=80=94 not that I've tried very hard to find out. =E2=80=93Arthur --=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/2adcd4e7-8711-4a6c-b5b6-8ea910e8b8bc%40isocpp.or= g. ------=_Part_188_594114577.1480239218659 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now that std::any, std::optional, and std::variant ha= ve blessed the idea of splitting each "perfectly forwarding emplacemen= t function" into a pair of functions, one taking initializer_list and = the other not, I wonder if there's any significant interest in retrofit= ting that solution onto the rest of the STL containers.

For example, to take this current wording in [forwardlist.modifiers]<= /div>

=09 =09 =09 
template &=
lt;class... Args> reference emplace_front(Args&&... args);
=09 =09 =09

Effects: Inserts a= n object of type value_type <= /span>constructed with value_type(std::forward<Args>( args)...) at the beginning o= f the list.=C2=A0


and replace it with this wording instead:= 

template <class... Args> reference emplac=
e_front(Args&&... args);

Effects:= =C2=A0Inserts an object of t= ype=C2=A0value_type=C2=A0constructed with=C2=A0value_type(std::forward<Args>( ar= gs)...)=C2=A0at the beginnin= g of the list.=C2=A0

=09 =09 =09
=09 =09 =09 =09

Remarks:=C2=A0This fu= nction shall not participate in overload resolution unless is_constructible_v<T, Args...> is true.


template <class U, class... Args> reference em=
place_front(initializer_list<U> il, Args&&... args);

Effects:= =C2=A0Inserts an object of t= ype=C2=A0value_type=C2=A0constructed with=C2=A0value_type(il, std::forward<Args>= ( args)...)=C2=A0at the begi= nning of the list.=C2=A0

Remarks:=C2=A0This function shall not participate in o= verload resolution unless=C2=A0is=C2=A0true.


and so on for std::vector, st= d::list, std::deque,...
Is there a technical reason this retrofitting ha= sn't happened, or is it just one of those "nobody's written th= e paper yet" cases?

Ville's N4462=C2=A0seems= to be a discussion of the "how to forward initializer_list" prob= lem in general, but AFAICT it dates from before the adoption of the two-fun= ction approach. I don't know where the two-function approach originally= came from =E2=80=94 not that I've tried very hard to find out.

=E2=80=93Arthur

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/2adcd4e7-8711-4a6c-b5b6-8ea910e8b8bc= %40isocpp.org.
------=_Part_188_594114577.1480239218659-- ------=_Part_187_1080890751.1480239218659-- .