Zhihao Yuan | 22 Oct 03:04 2013
Picon

A proposal to add `make_array`

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
(Continue reading)

Daryle Walker | 25 Oct 07:20 2013
Picon

Re: A proposal to add `make_array`

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  

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_pair don'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 <at> isocpp.org.
To post to this group, send email to std-proposals <at> isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
Zhihao Yuan | 25 Oct 08:04 2013
Picon

Re: Re: A proposal to add `make_array`

On Fri, Oct 25, 2013 at 1:20 AM, Daryle Walker <darylew <at> 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 <at> isocpp.org.
To post to this group, send email to std-proposals <at> isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

Daryle Walker | 25 Oct 22:56 2013
Picon

Re: Re: A proposal to add `make_array`

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... <at> 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, 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 <at> isocpp.org.
To post to this group, send email to std-proposals <at> isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
Zhihao Yuan | 25 Oct 23:10 2013
Picon

Re: Re: A proposal to add `make_array`

On Fri, Oct 25, 2013 at 4:56 PM, Daryle Walker <darylew <at> 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 <at> isocpp.org.
To post to this group, send email to std-proposals <at> isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

Daryle Walker | 26 Oct 23:49 2013
Picon

Re: Re: A proposal to add `make_array`

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... <at> 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 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::array has 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 <at> isocpp.org.
To post to this group, send email to std-proposals <at> isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

Gmane