220 16912 <7a747557-95d6-4484-a7d8-f18fcb05ee59@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Size deduction for std::array from initializer: Comments on n3824 std::make_array Date: Mon, 9 Mar 2015 12:17:24 -0700 (PDT) Lines: 443 Approved: news@gmane.org Message-ID: <7a747557-95d6-4484-a7d8-f18fcb05ee59@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_889_1714935834.1425928644945" X-Trace: ger.gmane.org 1425928678 11649 80.91.229.3 (9 Mar 2015 19:17:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Mar 2015 19:17:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBRPD66TQKGQESBDCHDI@isocpp.org Mon Mar 09 20:17:50 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YV3BE-00022X-8p for gclcip-std-proposals@m.gmane.org; Mon, 09 Mar 2015 20:17:32 +0100 Original-Received: by paceu11 with SMTP id eu11sf351988533pac.1 for ; Mon, 09 Mar 2015 12:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=/sVZWSudbl4vd7j88ibqn6ZI2T8lK6/Tn6TLnYGaNGg=; b=TILmS3N9qX43qsmh/SgAM8ryY/UC1fkrwQWRQDAj35Wwd7Juuox8R45jzFq8hLgXIX Cr2NSatyI3LJRtPP6//h87fdyWVXL4YvZb46yefyDzJfZtnCncRAH8nQVNUULgs/alxO Ik03ac931UTziaSDEFfy9Ccw667IG41SQFNTo82R7LlgHJeOe+wNO/Zo5D8IgrCRSFbs 1WnMiZB6sTgvAL8QhMgBc8FbbAYz+W/pjDW3H2wopI2BtJh/ertbvqiOa7cnEoD4Tc5M zOIOCqj5PmOkpfKF7QmqUU8m9zYPvik/MmuFIWIsg3pZ+h3eq6lh9d36/2I1O8bY0ppM 39cA== 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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=/sVZWSudbl4vd7j88ibqn6ZI2T8lK6/Tn6TLnYGaNGg=; b=DdAHav1iP7HumbC8O21Dl9NFEBAeXA8TmjIZ5LAybk1X8GZInlmoBlAidoXkA6E2Uu MGj0jAhPRymTN5iTpeSypWVtP/4grWB4HrNchFZQR2ywFs8pMs/ID4TMB0xnn5UFHCkn q/Zmgz3n5q9j2cmNSU2yOMODaZyUqt8maTzeHrBSrfq2dlGX0Unml9TViB5rHV9mwO/A jcRjg/t2CY63d18AImOR22dKXsbe/X8bCpbpijlo1wMTWJgmgQ2DPQev+5p+zMNQV41n 6+G6G8GrwhTf8GExgkQuqmiW4OdWXNRppH/JLMnV78MaGgm4wLRLQtxwT89Sekf+oFAl eRjA== X-Gm-Message-State: ALoCoQknmyZZeC7/9mbQzu9iPtq3UrNCyGS4udGvhTp0/bBBx+ERD1LiX6xkstZ5n1+Jly3RkwDF X-Received: by 10.66.160.34 with SMTP id xh2mr27129663pab.6.1425928646037; Mon, 09 Mar 2015 12:17:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.98.72 with SMTP id n66ls1731189qge.71.gmail; Mon, 09 Mar 2015 12:17:25 -0700 (PDT) X-Received: by 10.140.33.107 with SMTP id i98mr459406qgi.4.1425928645294; Mon, 09 Mar 2015 12:17:25 -0700 (PDT) X-Original-Sender: fmatthew5876@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:16912 Archived-At: ------=_Part_889_1714935834.1425928644945 Content-Type: multipart/alternative; boundary="----=_Part_890_1548535651.1425928644945" ------=_Part_890_1548535651.1425928644945 Content-Type: text/plain; charset=UTF-8 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3824.htm It seems that without being able to forward braced initializers this solution to "non-type template argument deduction" via a varidic make function is incomplete. struct Point { double x; double y; } //n3824 forces us to do this: auto a = make_array(Point{1.0, 2.0}, Point{3.0, 4.0}); //Should be able to do something like this: auto a = make_array( { 1.0, 2.0 }, { 3.0, 4.0 }); //This would be ok too auto a = make_array({{1.0, 2.0}, {3.0, 4.0}}); //This might be ideal std::array a = {{1.0, 2.0}, {3.0, 4.0}}; //For initialization, C array is still superior Point a[] = {{1.0, 2.0}, {3.0, 4.0}}; For a large array, typing Point{..} every time is redundant and also makes refactoring more painful. Are we sure this is the direction we want to go in? Is it really a good thing that initializing a C array and initializing a std::array with size deduction use different syntax with completely different rules? I can initialize a C array with braced initializers but I can't do it with std::array. Somewhat related, there are also issues with declaring and defining static data members with auto. Since we need to use auto with std::make_array, we also run into this problem: class A { static constexpr auto a = make_array(1, 2, 3); }; constexpr decltype(A::a) A::a; //Ugly, but it works template class B { static constexpr auto b = make_array(1, 2, 3); }; template constexpr decltype(B::b) B::b; //This is a compiler error (it works on some versions of gcc, doesn't work on clang, and according to standard should fail). As far as I can tell, there is no standard compliant way to write a definition for B::b without writing the exact type. The current workaround is to define the constants in a non-template base class and inherit publicly. One solution could be to reuse [] (or any other symbol which doesn't break legacy code): struct A { static constexpr std::array a = {{1.0, 2.0}, {3.0, 4.0}}; //Value of [] is deduced by number of initializers }; constexpr std::array A::a; //Looks for declaration to deduce [], compiler error if none can be found. constexpr std::array b; //Compiler error, deducing [] requires either an initializer or a previous declaration with an initializer. and if another proposal enables auto in template parameters, we can do this: std::array = { 1, 2, 3}; //is std::array -- --- 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_890_1548535651.1425928644945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014= /n3824.htm

It seems that without being able to forward braced in= itializers this solution to "non-type template argument deduction" via a va= ridic make function is incomplete.

struct Point { double<= span style=3D"color: #000;" class=3D"styled-by-prettify"> x; double y; }

//n3824 f= orces us to do this:
auto a= =3D make_array(Point{1.0, 2.0},= Point{3.0, 4.0});

//Should be able to do something like this:
auto a =3D make_array<Point>( { 1.0, 2.0 }, { 3.0, 4.0 });

//This would be ok too
auto a =3D make_array<P= oint>({= {1.0, 2.0}, {3.0, = 4.0}});

//This might be ideal=
std::array<Point,/*what goes here?*/> a =3D {{1.0<= /span>, 2.0}, {3.0, = 4.0= }};

//For initialization, C ar= ray is still superior
Point= a[] =3D {{1.0, 2.0}, {3.0, 4.0}};

For a large array, typing Point{..} e= very time is redundant and also makes refactoring more painful.

Are = we sure this is the direction we want to go in? Is it really a good=20 thing that initializing a C array and initializing a std::array with size d= eduction use=20 different syntax with completely different rules? I can initialize a C arra= y with braced initializers but I can't do it with std::array.


So= mewhat related, there are also issues with declaring and defining static da= ta members with auto. Since we need to use auto with std::make_array, we al= so run into this problem:

class A {=
  static constexpr auto a =3D make_array(1, 2<= /span>, 3);
};
constexpr = decltype(<= /span>A::a) A::a; //Ugly, but it= works
=
templa= te = <typename T>
class B {
  static con= stexpr auto b =3D make_array(1, 2,<= /span> 3);
};
template <typename= T>
constexpr decltype(B<T>::b) B<T>::b; //This is a compiler error (it works on some versions of gc= c, doesn't work on clang, and according to standard should fail).

As far as I can tell, there is no standard compliant way to w= rite a definition for B<T>::b without writing the exact type. The cur= rent workaround is to define the constants in a non-template base class and= inherit publicly.

One solution could be to reuse [] (or any other s= ymbol which doesn't break legacy code):

struct A {
  static constexpr std::array= <Point,[]> a =3D {{1.0, 2.0}, {3.0, 4.0}= }; = //Value of [] is = deduced by number of initializers
};
constexpr std::<= /span>array<Point,[]> A::a; //Looks for declaration to deduce [], compiler error if none can be f= ound.
<= br>constex= pr std::array<Point,[]> b; //Compiler error, deducing [] requires either an initializer or a p= revious declaration with an initializer.

and if anot= her proposal enables auto in template parameters, we can do this:

std::array<auto,[]> =3D { 1, 2, 3};<= /span> //is std::array<i= nt,3>



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_890_1548535651.1425928644945-- ------=_Part_889_1714935834.1425928644945-- .