220 16915 <6e1bae2e-8173-4437-a45b-63cddab072e5@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Size deduction for std::array from initializer: Comments on n3824 std::make_array Date: Mon, 9 Mar 2015 13:42:09 -0700 (PDT) Lines: 248 Approved: news@gmane.org Message-ID: <6e1bae2e-8173-4437-a45b-63cddab072e5@isocpp.org> References: <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_3879_1433758727.1425933729168" X-Trace: ger.gmane.org 1425933736 1195 80.91.229.3 (9 Mar 2015 20:42:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Mar 2015 20:42:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBIML7CTQKGQEUAGBSWI@isocpp.org Mon Mar 09 21:42:11 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f197.google.com ([209.85.216.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YV4V8-0006s5-UZ for gclcip-std-proposals@m.gmane.org; Mon, 09 Mar 2015 21:42:11 +0100 Original-Received: by qcyl6 with SMTP id l6sf43892546qcy.1 for ; Mon, 09 Mar 2015 13:42:10 -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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=yZtAzhnrGX4SPzWMfI+wZ/Ts1qQfIwRvhdNZQDPb2/Q=; b=rw3ByuMlnjnceQ6tv6TSSWrpkTcayI9qK5xMTf9CwDG5criBYeebNjxlcoxo6d2b+I UIzVcQsW0ayU6UU8qsRKKVCbvkcBvIkL3AMdHP3mZ/IqrgqLY9hgKj60Sjmm9+oKw8JJ Xo+JEbshxzBncWGu1jgmzb2mf31AMEcEkE/uQyUkg2Z8RjD66Tk4ngw2vlRg8t7HEqlM UWuXDvKO4RbmFFoME/cI+MtIITvYw5uur+U97rTGaoiIGpS8uN+3Mb32QANw6UOdr/Wu 0CqhKWhLKSeTHpNisioEo3jQUjAeNcVs/Q+Hl7HDzK5ja/kOQkQPXdNEv7VKMFnhWH9y DwSg== 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:in-reply-to:references :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=yZtAzhnrGX4SPzWMfI+wZ/Ts1qQfIwRvhdNZQDPb2/Q=; b=A8DM7+bzf6Z+iEXB2BvcvKDJh52j5+pHKSSWo2UchzvP/QS+PKoE2fR8HuvXpy/8LA Ux5GSShO7u2zJjll6R+f1epi88NnMVv0i/lqtw16hg35p+AELcWCRdCTwofzAS4MLejh uWrLejGkuLVMzOzjFkbQDHb+N3lMrwZTNOr98kNfrCkE04DjUtcs5WS+SOscpmMmo3Es sy/4CqkRh8Gg2yvIsIrODJZAWnnmgFl2dDd2r5zZcMHDdrikcQ4aCdyadjqkkcLdOSHq sIuMTrZ9fxQotyhdsya8svP7Q0Gm2wDfh1NLdNiiaPxLJV7XEVIngO5eNjVtak9QWE0b n31w== X-Gm-Message-State: ALoCoQm4tHIP/g+KBikji3cnij1wZua136DCgJCjTT5zroOwfjYNnQa7GaFLqkyG09DuXT+AAO3T X-Received: by 10.236.2.35 with SMTP id 23mr28272558yhe.22.1425933730039; Mon, 09 Mar 2015 13:42:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.31.102 with SMTP id e93ls1595873qge.87.gmail; Mon, 09 Mar 2015 13:42:09 -0700 (PDT) X-Received: by 10.140.33.202 with SMTP id j68mr485537qgj.27.1425933729539; Mon, 09 Mar 2015 13:42:09 -0700 (PDT) In-Reply-To: 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:16915 Archived-At: ------=_Part_3879_1433758727.1425933729168 Content-Type: multipart/alternative; boundary="----=_Part_3880_268921702.1425933729168" ------=_Part_3880_268921702.1425933729168 Content-Type: text/plain; charset=UTF-8 On Monday, March 9, 2015 at 4:15:16 PM UTC-4, Zhihao Yuan wrote: > > On Mon, Mar 9, 2015 at 3:17 PM, Matthew Fioravante > > wrote: > > 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 }); > > > > The problem of unable to perfect forward braced-init list > is a problem with uniform initialization itself, and applies > to everywhere, not limited to make_array, nor make_*. > If you want to solve it, go solve it. > Accepting make_array() is assuming that this problem will either be solved in the future or that its good enough having to live with it never being solved. Or is the standards committee ok with something now that might be obsoleted in the future should a better solution be found? > > > 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? > > Not "completely". While the language can do something > that library cannot, you will always have caveats, in lots > of places. But if we choose not to make a progress, we > are probably having bigger issues. > I'm concerned that we may be taking the wrong direction. If a language feature is invented to initialize std::array (and other similar templates) then make_array() may not be needed at all. A language feature also solves this problem for all possible template classes with non-type template size parameters. The make_array() approach means having to write a new make_X() method for each template class which might need it. Looking at your example implementation, writing ones own make_X() is non-trivial with all of the edge cases covered by type_traits. > > > > > 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). > > > > Sorry I don't know why this doesn't work. More like > clang's problem to me. > > From what I've found in my research (below bug report and an SO question which I cannot find now), this is standard mandated behavior. Gcc is wrong to accept it. http://lists.cs.uiuc.edu/pipermail/llvmbugs/2013-January/026679.html This issue however might be fixable with its own proposal. > > and if another proposal enables auto in template parameters, we can do > this: > > > > std::array = { 1, 2, 3}; //is std::array > > > > Even with that proposal, it still may not work > because { ... } with auto will very likely be deduced > to std::initializer_list, or simply not supported, > but std::array is required to have no (user-declared) > constructor. > This is not really a problem. If you just write a braced initializer and say auto the compiler of course has no idea what you want. If you want points you must say Point somewhere (hopefully only once). -- --- 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_3880_268921702.1425933729168 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, March 9, 2015 at 4:15:16 PM UTC-4, Zhih= ao Yuan wrote:
On Mon, Mar 9, 2= 015 at 3:17 PM, Matthew Fioravante
<fmatth...@gma= il.com> wrote:
> http://www.open-std.org/jtc1/sc= 22/wg21/docs/papers/2014/n3824.htm
>
> It seems that without being able to forward braced initializers th= is
> solution to "non-type template argument deduction" via a varidic m= ake
> function is incomplete.
>
> struct Point { double x; double y; }
>
> //n3824 forces 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 });
>

The problem of unable to perfect forward braced-init list
is a problem with uniform initialization itself, and applies
to everywhere, not limited to make_array, nor make_*.
If you want to solve it, go solve it.

Accepting make_array() is assuming that this prob= lem will either be solved in the future or that its good enough having to l= ive with it never being solved. Or is the standards committee ok with somet= hing now that might be obsoleted in the future should a better solution be = found?
 

> Is it really a good
> thing that initializing a C array and initializing a std::array wi= th size
> deduction use different syntax with completely different rules?

Not "completely".  While the language can do something
that library cannot, you will always have caveats, in lots
of places.  But if we choose not to make a progress, we
are probably having bigger issues.

I'm concerned that we may be taking the wrong dir= ection. If a language feature is invented to initialize std::array (and oth= er similar templates) then make_array() may not be needed at all. A languag= e feature also solves this problem for all possible template classes with n= on-type template size parameters. The make_array() approach means having to= write a new make_X() method for each template class which might need it. L= ooking at your example implementation, writing ones own make_X() is non-tri= vial with all of the edge cases covered by type_traits.
 

>
> class A {
>   static constexpr auto a =3D make_array(1, 2, 3);
> };
> constexpr decltype(A::a) A::a; //Ugly, but it works
>
> template <typename T>
> class B {
>   static constexpr auto b =3D make_array(1, 2, 3);
> };
> template <typename T>
> constexpr decltype(B<T>::b) B<T>::b; //This is a compi= ler error (it works on
> some versions of gcc, doesn't work on clang, and according to stan= dard
> should fail).
>

Sorry I don't know why this doesn't work.  More like
clang's problem to me.


From what I've found in my research (below bug re= port and an SO question which I cannot find now), this is standard mandated= behavior. Gcc is wrong to accept it.

http://lists.cs.uiuc.edu/piper= mail/llvmbugs/2013-January/026679.html

This issue however might be f= ixable with its own proposal.
 
> and if another proposal enables auto in template parame= ters, we can do this:
>
> std::array<auto,[]> =3D { 1, 2, 3}; //is std::array<int,3= >
>

Even with that proposal, it still may not work
because { ... } with auto will very likely be deduced
to std::initializer_list<int>, or simply not supported,
but std::array is required to have no (user-declared)
constructor.

This is not really a problem. If you just write a= braced initializer and say auto the compiler of course has no idea what yo= u want. If you want points you must say Point somewhere (hopefully only onc= e).

--

---
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_3880_268921702.1425933729168-- ------=_Part_3879_1433758727.1425933729168-- .