The idea of a utility to simplify std::array creation has been
around for a long time, now I wrote a formal paper to
address that:

  http://students.cs.niu.edu/~z1565938/make_array.html

Roughly, I included two signatures to support three uses:

  make_array(a, b, c, ...)  // an std::array of common_type
  make_array<T>(a, b, c, ...)  // an std::array of T

  to_array("raw array")  // create an std::array from a raw array

Hope I can get some reviews.  Thanks :)

PS: I noticed that the first signature conflicts with the one
included in N3794, but I kept mine because I think the idea
of creating a multidimensional array through a one
dimensional syntax is flawed.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_375_16489800.1382678411145
Content-Type: text/plain; charset=ISO-8859-1

On Monday, October 21, 2013 9:04:29 PM UTC-4, Zhihao Yuan wrote:

> The idea of a utility to simplify std::array creation has been
> around for a long time, now I wrote a formal paper to
> address that:
>
>   http://students.cs.niu.edu/~z1565938/make_array.html <http://students.cs.niu.edu/~z1565938/make_array.html>
>
>

I read about this idea too. That's why I added it to N3794.


> Roughly, I included two signatures to support three uses:
>
>   make_array(a, b, c, ...)  // an std::array of common_type
>   make_array<T>(a, b, c, ...)  // an std::array of T
>
>   to_array("raw array")  // create an std::array from a raw array
>
> Hope I can get some reviews.  Thanks :)
>

I originally had just a "make_array" like yours. But there were complaints
about leaving the choice of element type to std::common_type, and wanting a
manual override. Then I remembered that make_shared (and the new make_unique)
require the user to specify the return type via explicit template arguments
to the creation function. That's why I changed the signature for make_array,
and made a new function make_auto_array with the automatically-chosen
element type semantics. (You just reminded me that make_tuple and make_pairdon't need explicit template arguments, but they allow the element types to
not match each other.)

You made your version of "make_auto_array" an overload(?) of the regular
make_array. How can they co-exist without ambiguities? Especially if the
first function argument's type matches that of your explicitly given
element type?


> PS: I noticed that the first signature conflicts with the one
> included in N3794, but I kept mine because I think the idea
> of creating a multidimensional array through a one
> dimensional syntax is flawed.
>

My versions of the creation functions don't require multidimensionality;
they can be made to work with a single-dimension-only std::array. I added
them late in the process. I was already adding major changes to that
section of the Standard, so why not add a common request.

AFAIK, function-call syntax is linear, so what would alternatives for
creating multidimensional arrays via functions be (besides giving up and
use aggregate initialization only)? Nested calls to make_array, as
mentioned in your paper? (I couldn't do that in my paper, since my proposed
array directly uses a C-level multidimensional array, and not nested
instantiations of array. Recall that built-in multidimensional arrays can
be "sloppily" initialized linearly.)

Daryle W.

--

---
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_375_16489800.1382678411145
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, October 21, 2013 9:04:29 PM UTC-4, Zhihao Yuan =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The idea of a utilit=
y to simplify std::array creation has been
<br>around for a long time, now I wrote a formal paper to
<br>address that:
<br>
<br>&nbsp; <a href=3D"http://students.cs.niu.edu/~z1565938/make_array.html"=
 target=3D"_blank">http://students.cs.niu.edu/~<wbr>z1565938/make_array.htm=
l&nbsp;</a>&nbsp;<br></blockquote><div><br></div><div>I read about this ide=
a too. That's why I added it to N3794.</div><div>&nbsp;<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">Roughly, I included two signatures to su=
pport three uses:
<br>
<br>&nbsp; make_array(a, b, c, ...) &nbsp;// an std::array of common_type
<br>&nbsp; make_array&lt;T&gt;(a, b, c, ...) &nbsp;// an std::array of T
<br>
<br>&nbsp; to_array("raw array") &nbsp;// create an std::array from a raw a=
rray
<br>
<br>Hope I can get some reviews. &nbsp;Thanks :)
<br></blockquote><div><br></div><div>I originally had just a "<font face=3D=
"courier new, monospace">make_array</font>" like yours. But there were comp=
laints about leaving the choice of element type to <font face=3D"courier ne=
w, monospace">std::common_type</font>, and wanting a manual override. Then =
I remembered that <font face=3D"courier new, monospace">make_shared</font> =
(and the new <font face=3D"courier new, monospace">make_unique</font>) requ=
ire the user to specify the return type via explicit template arguments to =
the creation function. That's why I changed the signature for <font face=3D=
"courier new, monospace">make_array</font>, and made a new function <font f=
ace=3D"courier new, monospace">make_auto_array</font> with the automaticall=
y-chosen element type semantics. (You just reminded me that <font face=3D"c=
ourier new, monospace">make_tuple</font> and <font face=3D"courier new, mon=
ospace">make_pair</font> don't need explicit template arguments, but they a=
llow the element types to not match each other.)</div><div><br></div><div>Y=
ou made your version of "make_auto_array" an overload(?) of the regular <fo=
nt face=3D"courier new, monospace">make_array</font>. How can they co-exist=
 without ambiguities? Especially if the first function argument's type matc=
hes that of your explicitly given element type?</div><div>&nbsp;<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">PS: I noticed that the first si=
gnature conflicts with the one
<br>included in N3794, but I kept mine because I think the idea
<br>of creating a multidimensional array through a one
<br>dimensional syntax is flawed.
<br></blockquote><div><br></div><div>My versions of the creation functions =
don't require multidimensionality; they can be made to work with a single-d=
imension-only <font face=3D"courier new, monospace">std::array</font>. I ad=
ded them late in the process. I was already adding major changes to that se=
ction of the Standard, so why not add a common request.</div><div><br></div=
><div>AFAIK, function-call syntax is linear, so what would alternatives for=
 creating multidimensional arrays via functions be (besides giving up and u=
se aggregate initialization only)? Nested calls to <font face=3D"courier ne=
w, monospace">make_array</font>, as mentioned in your paper? (I couldn't do=
 that in my paper, since my proposed&nbsp;<font face=3D"courier new, monosp=
ace">array</font> directly uses a C-level multidimensional array, and not n=
ested instantiations of <font face=3D"courier new, monospace">array</font>.=
 Recall that built-in multidimensional arrays can be "sloppily" initialized=
 linearly.)</div><div><br></div><div>Daryle W.</div><div><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_375_16489800.1382678411145--

.

On Fri, Oct 25, 2013 at 1:20 AM, Daryle Walker <darylew@gmail.com> wrote:
> You made your version of "make_auto_array" an overload(?) of the regular
> make_array. How can they co-exist without ambiguities? Especially if the
> first function argument's type matches that of your explicitly given element
> type?

Because they are overloaded on template parameters,
not function parameters, so they are disambiguated during
substitution.  (unless user supplies deduced template
parameters, which is just a wrong use)

> AFAIK, function-call syntax is linear, so what would alternatives for
> creating multidimensional arrays via functions be (besides giving up and use
> aggregate initialization only)? Nested calls to make_array, as mentioned in
> your paper? (I couldn't do that in my paper, since my proposed array
> directly uses a C-level multidimensional array, and not nested
> instantiations of array. Recall that built-in multidimensional arrays can be
> "sloppily" initialized linearly.)

If C++ supports C99 array literals then my `to_array` can
be extended to do this, but, you know :)

Anyway, a solution I can think of is to use a special deduction
rule, like to deduce `reference_wrapper<T>` to `T&`, deduce
a proxy type to initialize a C array.

But TBH, I worry about the internal C array solution itself.  One
of the major benefit of std::array is that it does not decay into
a pointer, while your design, iiuc, will decay from the second
level.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_1061_559889.1382734617996
Content-Type: text/plain; charset=ISO-8859-1

On Friday, October 25, 2013 2:04:36 AM UTC-4, Zhihao Yuan wrote:

> On Fri, Oct 25, 2013 at 1:20 AM, Daryle Walker <dar...@gmail.com<javascript:>>
> wrote:
> > You made your version of "make_auto_array" an overload(?) of the regular
> > make_array. How can they co-exist without ambiguities? Especially if the
> > first function argument's type matches that of your explicitly given
> element
> > type?
>
> Because they are overloaded on template parameters,
> not function parameters, so they are disambiguated during
> substitution.  (unless user supplies deduced template
> parameters, which is just a wrong use)
>

AFAIK, you can explicitly fill in any template parameter for current
Standard function templates. Your function templates would be the first
ones where explicit filling will break stuff. Maybe we should use distinct
function names like I did.


> > AFAIK, function-call syntax is linear, so what would alternatives for
> > creating multidimensional arrays via functions be (besides giving up and
> use
> > aggregate initialization only)? Nested calls to make_array, as mentioned
> in
> > your paper? (I couldn't do that in my paper, since my proposed array
> > directly uses a C-level multidimensional array, and not nested
> > instantiations of array. Recall that built-in multidimensional arrays
> can be
> > "sloppily" initialized linearly.)
>
> If C++ supports C99 array literals then my `to_array` can
> be extended to do this, but, you know :)
>
> Anyway, a solution I can think of is to use a special deduction
> rule, like to deduce `reference_wrapper<T>` to `T&`, deduce
> a proxy type to initialize a C array.
>
> But TBH, I worry about the internal C array solution itself.  One
> of the major benefit of std::array is that it does not decay into
> a pointer, while your design, iiuc, will decay from the second
> level.
>

I'm not sure what you're talking about by "my design"? If you mean my
off-the-cuff suggestion, then that "make_array" returns std::array objects,
so no decay. If you mean N3794, then that "make_array" takes a linear list
of T objects, so no decay (unless T itself is an array type, but you're
already screwed in that case since built-in arrays are not Assignable).

Daryle W.


--

---
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_1061_559889.1382734617996
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 25, 2013 2:04:36 AM UTC-4, Zhihao Yuan =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Oct 25, 2013=
 at 1:20 AM, Daryle Walker &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"ClrZAEAFi6cJ">dar...@gmail.com</a>&gt; wrote:
<br>&gt; You made your version of "make_auto_array" an overload(?) of the r=
egular
<br>&gt; make_array. How can they co-exist without ambiguities? Especially =
if the
<br>&gt; first function argument's type matches that of your explicitly giv=
en element
<br>&gt; type?
<br>
<br>Because they are overloaded on template parameters,
<br>not function parameters, so they are disambiguated during
<br>substitution. &nbsp;(unless user supplies deduced template
<br>parameters, which is just a wrong use)
<br></blockquote><div><br></div><div>AFAIK, you can explicitly fill in any =
template parameter for current Standard function templates. Your function t=
emplates would be the first ones where explicit filling will break stuff. M=
aybe we should use distinct function names like I did.</div><div>&nbsp;<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; AFAIK, function-cal=
l syntax is linear, so what would alternatives for
<br>&gt; creating multidimensional arrays via functions be (besides giving =
up and use
<br>&gt; aggregate initialization only)? Nested calls to make_array, as men=
tioned in
<br>&gt; your paper? (I couldn't do that in my paper, since my proposed arr=
ay
<br>&gt; directly uses a C-level multidimensional array, and not nested
<br>&gt; instantiations of array. Recall that built-in multidimensional arr=
ays can be
<br>&gt; "sloppily" initialized linearly.)
<br>
<br>If C++ supports C99 array literals then my `to_array` can
<br>be extended to do this, but, you know :)
<br>
<br>Anyway, a solution I can think of is to use a special deduction
<br>rule, like to deduce `reference_wrapper&lt;T&gt;` to `T&amp;`, deduce
<br>a proxy type to initialize a C array.
<br>
<br>But TBH, I worry about the internal C array solution itself. &nbsp;One
<br>of the major benefit of std::array is that it does not decay into
<br>a pointer, while your design, iiuc, will decay from the second
<br>level.
<br></blockquote><div><br></div><div>I'm not sure what you're talking about=
 by "my design"? If you mean my off-the-cuff suggestion, then that "make_ar=
ray" returns std::array objects, so no decay. If you mean N3794, then that =
"make_array" takes a linear list of T objects, so no decay (unless T itself=
 is an array type, but you're already screwed in that case since built-in a=
rrays are not Assignable).</div><div><br></div><div>Daryle W.</div><div>&nb=
sp;</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_1061_559889.1382734617996--

.

On Fri, Oct 25, 2013 at 4:56 PM, Daryle Walker <darylew@gmail.com> wrote:
> AFAIK, you can explicitly fill in any template parameter for current
> Standard function templates. Your function templates would be the first ones
> where explicit filling will break stuff.

So now you can't, which is a good thing.  Filling deduced
template parameter is a wrong use and is *not* supported
by standard library:

  http://channel9.msdn.com/Events/GoingNative/2013/Don-t-Help-the-Compiler

> I'm not sure what you're talking about by "my design"?

I'm talking about your design of multidimensional `std::array`,
not `make_array`.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_457_14939615.1382824166380
Content-Type: text/plain; charset=ISO-8859-1

On Friday, October 25, 2013 5:10:56 PM UTC-4, Zhihao Yuan wrote:

> On Fri, Oct 25, 2013 at 4:56 PM, Daryle Walker <dar...@gmail.com<javascript:>>
> wrote:
> > AFAIK, you can explicitly fill in any template parameter for current
> > Standard function templates. Your function templates would be the first
> ones
> > where explicit filling will break stuff.
>
> So now you can't, which is a good thing.  Filling deduced
> template parameter is a wrong use and is *not* supported
> by standard library:
>
>   http://channel9.msdn.com/Events/GoingNative/2013/Don-t-Help-the-Compiler
>
>
I just realized something else that was different between our
implementations. You have an overload of make_array with automatic
deduction of type and length, and another one where you can override the
type. But you don't allow an override of the length; the returned std::arrayhas its length always fitted to the number of passed arguments. My proposal
has either neither explicitly given (make_auto_array) or both explicitly
given (make_array). My make_array has to get the extents too because I have
to support extent counts besides one and therefore can't assume a fitted
linear array. (If you give it a type without any following extents, then a
zero-dimension array is used.)

This makes the proposals differ when a zero-length array is desired.

make_array<ElementType>( /*nothing*/ );  // your proposal
make_array<ElementType, 0 /*, Whatever...*/>( /*nothing*/ );  // my proposal

A user can't use the creation functions that use std::common_type (from
either proposal) since that template isn't defined when given zero
arguments.

Daryle W.

--

---
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_457_14939615.1382824166380
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 25, 2013 5:10:56 PM UTC-4, Zhihao Yuan =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Oct 25, 2013=
 at 4:56 PM, Daryle Walker &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"rjQs2QgKzwUJ">dar...@gmail.com</a>&gt; wrote:
<br>&gt; AFAIK, you can explicitly fill in any template parameter for curre=
nt
<br>&gt; Standard function templates. Your function templates would be the =
first ones
<br>&gt; where explicit filling will break stuff.
<br>
<br>So now you can't, which is a good thing. &nbsp;Filling deduced
<br>template parameter is a wrong use and is *not* supported
<br>by standard library:
<br>
<br>&nbsp; <a href=3D"http://channel9.msdn.com/Events/GoingNative/2013/Don-=
t-Help-the-Compiler" target=3D"_blank">http://channel9.msdn.com/<wbr>Events=
/GoingNative/2013/Don-t-<wbr>Help-the-Compiler</a>
<br>
<br></blockquote><div><br></div><div>I just realized something else that wa=
s different between our implementations. You have an overload of <font face=
=3D"courier new, monospace">make_array</font> with automatic deduction of t=
ype and length, and another one where you can override the type. But you do=
n't allow an override of the length; the returned <font face=3D"courier new=
, monospace">std::array</font> has its length always fitted to the number o=
f passed arguments. My proposal has either neither explicitly given (<font =
face=3D"courier new, monospace">make_auto_array</font>) or both explicitly =
given (<font face=3D"courier new, monospace">make_array</font>). My <font f=
ace=3D"courier new, monospace">make_array</font> has to get the extents too=
 because I have to support extent counts besides one and therefore can't as=
sume a fitted linear array. (If you give it a type without any following ex=
tents, then a zero-dimension array is used.)</div><div><br></div><div>This =
makes the proposals differ when a zero-length array is desired.</div><div><=
br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#000;" class=3D"styled-by-prettify">make_array</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">ElementType</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">/*nothing*/</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 your proposal</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>make_array</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">ElementType</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">/*, Whatever...*/</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">/*nothing*/</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> &nbsp;</span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// my proposal</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></div></code></div><div><br>A user can't use=
 the creation functions that use <font face=3D"courier new, monospace">std:=
:common_type</font> (from either proposal) since that template isn't define=
d when given zero arguments.</div><div><br></div><div>Daryle W.</div><div><=
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_457_14939615.1382824166380--

.