array to std::array standard conversion

[Andrew Tomazos]

We propose the following two new standard conversions:

    1. A value of type "derived-declarator-type-list array of N T" of value category VC can be converted to a value of type "derived-declarator-type-list std::array<T,N>" of value category VC.

    2. A value of type "derived-declarator-type-list std::array<T,N>" of value category VC can be converted to a value of type "derived-declarator-type-list array of N T" of value category VC.

It isn't 100% clear whether the two families of types are required to have identical representations, but in practice they surely do (don't they?).  The conversion is therefore simply a static substitution of the types.

We also propose the introduction of initialization of built-in array types by values of built-in array types.  For initialization of arrays of unknown bound, the bound is inferred by the initializer as you would expect.  This doesn't break compatibility with C, because this is ill-formed in C.

This would allow the following for example:

    int x[] = {1, 2, 3};

    int y[] = x;

    std::array<int,3> z = x;

    int w[] = z;

    std::array<int, 3> times2(std::array<int, 3> A)

    {

        for (auto& a : A)

           a *= 2;

        return A;

    }

    int t[] = times2(w);

It essentially means std::array and array types are completely interchangeable, and become almost the same type.  std::array remains necessary for the original purpose it was introduced, to specify return types and parameter types as arrays, because for backward compatibility with C built-in array types in such positions essentially become pointers.  For the remainder we become free to use the nicer built-in array declarator and unknown bound rules.  We might also effectively get all the member functions of std::array on builtin arrays:

    int u[] = {42, 43};

    int v = u.front(); // v = 42

Feedback on this idea appreciated.

   -Andrew.

[Thiago Macieira]

Em dom 20 abr 2014, às 00:08:44, Andrew Tomazos escreveu:
> We propose the following two new standard conversions:
>
> 1. A value of type "derived-declarator-type-list array of N T" of value
> category VC can be converted to a value of type
> "derived-declarator-type-list std::array<T,N>" of value category VC.
> 2. A value of type "derived-declarator-type-list std::array<T,N>" of
> value category VC can be converted to a value of type
> "derived-declarator-type-list array of N T" of value category VC.

Can you specify this in such a way I can do the same for QVarLengthArray?
I.e., please give me the underlying tools instead of writing "std::array" in
the spec.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[David Krauss]

On 2014–04–21, at 2:44 AM, Thiago Macieira <thi...@macieira.org> wrote:

Em dom 20 abr 2014, às 00:08:44, Andrew Tomazos escreveu:

We propose the following two new standard conversions:

   1. A value of type "derived-declarator-type-list array of N T" of value
category VC can be converted to a value of type
"derived-declarator-type-list std::array<T,N>" of value category VC.
   2. A value of type "derived-declarator-type-list std::array<T,N>" of
value category VC can be converted to a value of type
"derived-declarator-type-list array of N T" of value category VC.

Can you specify this in such a way I can do the same for QVarLengthArray?
I.e., please give me the underlying tools instead of writing "std::array" in
the spec.

I think std::array_view is supposed to be the general solution, no?

These conversions seem way more trouble than they’re worth, given that. For one thing, user specializations would have to be disallowed.

By the way, what is derived-declarator-type-list? It seems to be an occasionally used meta-variable, but it has no single definition per se. Perhaps it was a grammar production in pre-standard drafts.

[Andrew Tomazos]

On Monday, April 21, 2014 5:50:34 AM UTC+2, David Krauss wrote:

I think std::array_view is supposed to be the general solution, no?

 

The general solution to what?  std::string_view and std::array_view provide a non-owning reference type to a subsequence of a string-like or array-like container.  It isn't clear what relevance they have to this proposal.  The purpose of this proposal is to bring parity between built-in array types and std::array.  It is a kind of simplification.

These conversions seem way more trouble than they’re worth, given that. For one thing, user specializations would have to be disallowed.

User specializations of what?  And why would they have to be disallowed?  And what are the other things apart from this "one thing"?

By the way, what is derived-declarator-type-list? It seems to be an occasionally used meta-variable, but it has no single definition per se. Perhaps it was a grammar production in pre-standard drafts.

It just means some (possibly empty) prefix of compound type declarators.  For example "reference to const pointer to":

    int (* const & x) [10] = ...;

    std::array<int, 10>* const & y = x; // ok

[David Krauss]

On 2014–04–21, at 2:07 PM, Andrew Tomazos <andrew...@gmail.com> wrote:

On Monday, April 21, 2014 5:50:34 AM UTC+2, David Krauss wrote:

I think std::array_view is supposed to be the general solution, no?

 

The general solution to what?  std::string_view and std::array_view provide a non-owning reference type to a subsequence of a string-like or array-like container.  It isn't clear what relevance they have to this proposal.  The purpose of this proposal is to bring parity between built-in array types and std::array.  It is a kind of simplification.

If you are writing an interface that needs that conversion, have it take an array_view instead. If it’s owning a copy, it needs a std::array anyway. If array_view has an implicit conversion function to array, then the user may idiomatically pass array_view “by value” without caring about ownership. Such a conversion doesn’t require changing the core language.

These conversions seem way more trouble than they’re worth, given that. For one thing, user specializations would have to be disallowed.

User specializations of what?  And why would they have to be disallowed?  And what are the other things apart from this "one thing”?

User specializations of std::array don’t need to have (and usually won’t have) the same representation and lifetime semantics as the naked array, needed to make the conversion work.

The proposal seems to be essentially about changing the lifetime of an object in-flight, which may get messy in the object lifetime model. I’m not really sure what is the use for changing type and ownership simultaneously, though, as opposed to just providing a non-owning view.

By the way, what is derived-declarator-type-list? It seems to be an occasionally used meta-variable, but it has no single definition per se. Perhaps it was a grammar production in pre-standard drafts.

It just means some (possibly empty) prefix of compound type declarators.  For example "reference to const pointer to":

    int (* const & x) [10] = ...;

    std::array<int, 10>* const & y = x; // ok

I see. This is like the qualification conversion rule, in that it works at any level and not only the “top.” 

Unlike other standard conversions, you would also want to apply it recursively, to handle multidimensional arrays.

[David Krauss]

On 2014–04–21, at 3:21 PM, David Krauss <pot...@gmail.com> wrote:

> The proposal seems to be essentially about changing the lifetime of an object in-flight

Oops, changing the *type* of an object in-flight. It looks like you would want to be able to destroy the object through a converted expression, is that right?

[Andrew Tomazos]

I don't really follow what you are saying.  Can you give a code example of the type of an object changing "in-flight" due to the conversion?

[Matthew Fioravante]

I'd really like to just see a shorthand for declaring std::array objects, with compiler warnings enabled for declaring now depreciated C arrays. C arrays with their pointer decaying behavior are really annoying to use and have a lot of pitfalls. Arrays should be separate types with value semantics like everything else in C++. The only use I could see for C array is C compatibility.

std::array<std::array<int, 5>, 10> a; is ugly as hell, its really the only reason I still use C arrays sometimes.

Some possibilities for syntax:

Single dimension arrays with known size
int x[{5}];
int x[[5]]; //maybe this clashes with attribute syntax?
int[5] x;


Multi dimensional arrays
int x[{10}{5}]; //shorthand for std::array<std::array<int, 5>, 10>
int x[10,5];
int x[[10][5]];
int[10][5] x;

Arrays of unknown bound with explicit type
int x[{}] = {1, 3, 4}; //becomes std::array<int, 3> = {1, 3, 4};
int x[[]] = { 1, 3, 4};
int[] x = { 1, 3, 4};

Arrays of unknown bound with deduced type using auto
//auto doesn't work for C arrays, so we could use auto with [] for std::array
auto x[] = { 1, 2, 3 }; //becomes std::array<int, 3> = {1, 2, 3};
auto x[{}] = { 1, 2, 3};
auto x[[]] = { 1, 2, 3};
auto[] x = { 1, 2, 3};

auto x[] = { 1, 2L, 3}; //compiler error, cannot deduce the type

[Nevin Liber]

On 20 April 2014 02:08, Andrew Tomazos <andrew...@gmail.com> wrote:

We propose the following two new standard conversions:

    1. A value of type "derived-declarator-type-list array of N T" of value category VC can be converted to a value of type "derived-declarator-type-list std::array<T,N>" of value category VC.

    2. A value of type "derived-declarator-type-list std::array<T,N>" of value category VC can be converted to a value of type "derived-declarator-type-list array of N T" of value category VC.

What about aliasing rules?

If I have:

template<size_t N>

void foo(int(&a)[N], std::array<int, N>& b)

does the compiler have to now assume a may be an alias for b?

--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[Nevin Liber]

On 23 April 2014 13:49, Matthew Fioravante <fmatth...@gmail.com> wrote:

I'd really like to just see a shorthand for declaring std::array objects, with compiler warnings enabled for declaring now depreciated C arrays.

C arrays are not deprecated.

[Matthew Fioravante]

I meant that they would be depreciated after the new syntax becomes available.

[Nevin Liber]

On 23 April 2014 14:27, Matthew Fioravante <fmatth...@gmail.com> wrote:

I meant that they would be depreciated after the new syntax becomes available.

We should deprecated a huge body of currently working code, as well as C compatibility?  Why??

[Nicola Gigante]

Il giorno 23/apr/2014, alle ore 20:49, Matthew Fioravante <fmatth...@gmail.com> ha scritto:

> I'd really like to just see a shorthand for declaring std::array objects, with compiler warnings enabled for declaring now depreciated C arrays. C arrays with their pointer decaying behavior are really annoying to use and have a lot of pitfalls. Arrays should be separate types with value semantics like everything else in C++. The only use I could see for C array is C compatibility.
>
> std::array<std::array<int, 5>, 10> a; is ugly as hell, its really the only reason I still use C arrays sometimes.

You don't need a language extension to simplify it:

#include <type_traits>
#include <array>

template<typename T>
class convert_array {
public:
using type = T;
};

template<typename T, size_t N>
class convert_array<T[N]>
{
public:
using type = std::array<typename convert_array<T>::type, N>;
};

template<typename T>
using array = typename convert_array<T>::type;

int main()
{
array<int[2][3]> matrix3d;

matrix3d[1][2] = 42;

return 0;
}


Bye,
Nicola

[Matthew Fioravante]

Other than maintaining C compatibility, the ugly syntax of std::array, and unbounded initialization. Can you name one reason why someone should prefer to still use C arrays? Why should we continue to suggest that programmers use C arrays if we have a replacement that is better on all accounts except for a few backwards compatible edge cases?

Its already terrible that we have 2 different fixed size array types and we have to teach new programmers the differences between them. Even worse that the most natural syntax is for the one that should be avoided. This kind of legacy cruft is what makes people run screaming to other languages.

[Matthew Fioravante]

On Wednesday, April 23, 2014 4:09:18 PM UTC-4, Nicola Gigante wrote:

You don't need a language extension to simplify it:

#include <type_traits>
#include <array>

template<typename T>
class convert_array {
public:
    using type = T;
};

template<typename T, size_t N>
class convert_array<T[N]>
{
public:
    using type = std::array<typename convert_array<T>::type, N>;
};

template<typename T>
using array = typename convert_array<T>::type;

int main()
{
    array<int[2][3]> matrix3d;
   
    matrix3d[1][2] = 42;
   
    return 0;
}


Bye,
Nicola

That's elegant, but it doesn't work with unbounded initialization.

I can't say array<int[]> = { 1, 2, 3};

That requires a language extension. Either a special case for array syntax, or a new proposal for constexpr constructors which can deduce template arguments from constructor arguments.

[Nevin Liber]

On 23 April 2014 15:26, Matthew Fioravante <fmatth...@gmail.com> wrote:

Other than maintaining C compatibility, the ugly syntax of std::array, and unbounded initialization. Can you name one reason why someone should prefer to still use C arrays?

Backwards compatibility.  Why should I change millions of lines of working code just because *you* want to deprecate this?

 

Why should we continue to suggest that programmers use C arrays if we have a replacement that is better on all accounts except for a few backwards compatible edge cases?

Who says we should suggest programmers use C arrays?  Quit making straw man arguments.

 

Its already terrible that we have 2 different fixed size array types and we have to teach new programmers the differences between them. Even worse that the most natural syntax is for the one that should be avoided. This kind of legacy cruft is what makes people run screaming to other languages.

"legacy" is a two-edged sword.  It's a major reason people move to C++, and a major reason for many of the whines.  I fail to see any evidence that gratuitously breaking backwards compatibility will *retain* C++ developers.

[Tony V E]

On Wed, Apr 23, 2014 at 2:49 PM, Matthew Fioravante <fmatth...@gmail.com> wrote:

I'd really like to just see a shorthand for declaring std::array objects, with compiler warnings enabled for declaring now depreciated C arrays. C arrays with their pointer decaying behavior are really annoying to use and have a lot of pitfalls. Arrays should be separate types with value semantics like everything else in C++. The only use I could see for C array is C compatibility.

std::array<std::array<int, 5>, 10> a; is ugly as hell, its really the only reason I still use C arrays sometimes.

Some possibilities for syntax:

Single dimension arrays with known size
int x[{5}];
int x[[5]]; //maybe this clashes with attribute syntax?
int[5] x;

int[5] x;  for sure.

I'm not even sure what I think about the entire proposal, but if we had new array syntax, this should be it.  I wish it worked with current arrays.  If it was reserved for value-type non-decaying arrays, that would be great.

But what about unnamed function params:

void f(int [5] );

could that mean either array type?

[Matthew Fioravante]

On Wednesday, April 23, 2014 4:39:05 PM UTC-4, Nevin ":-)" Liber wrote:

On 23 April 2014 15:26, Matthew Fioravante <fmatth...@gmail.com> wrote:

Other than maintaining C compatibility, the ugly syntax of std::array, and unbounded initialization. Can you name one reason why someone should prefer to still use C arrays?

Backwards compatibility.  Why should I change millions of lines of working code just because *you* want to deprecate this?

Lets not make this personal. Nobody is doing anything for me or for anyone else. If the C++ community generally agrees that std::array is a better construct than C arrays, why shouldn't they find ways to encourage developers to adopt the new style?

 

 

Why should we continue to suggest that programmers use C arrays if we have a replacement that is better on all accounts except for a few backwards compatible edge cases?

Who says we should suggest programmers use C arrays?  Quit making straw man arguments.

Throwing a compiler warning is a great way to suggest someone not use something. Not doing so makes it seem like fair game. I don't know about you, but I'd love for my compiler to find all of these instances for me so that I can fix them.
 

 

Its already terrible that we have 2 different fixed size array types and we have to teach new programmers the differences between them. Even worse that the most natural syntax is for the one that should be avoided. This kind of legacy cruft is what makes people run screaming to other languages.

"legacy" is a two-edged sword.  It's a major reason people move to C++, and a major reason for many of the whines.  I fail to see any evidence that gratuitously breaking backwards compatibility will *retain* C++ developers.

Nothing is breaking backwards compatibility. I'm not suggesting C arrays ever get removed from the standard, doing such would break C compatibility. Instead I'm suggesting discouraging their use to only the cases where they are really needed, which is extern "C" code. Maybe depreciated is too strong a word here, perhaps "discouraged" is better.

--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

Discouraging the use of C arrays from modern C++ would also mean that library writers can stop needing to write special cases for arrays and decaying in their template interfaces.
 

[Nevin Liber]

On 23 April 2014 16:05, Matthew Fioravante <fmatth...@gmail.com> wrote:

If the C++ community generally agrees that std::array is a better construct than C arrays, why shouldn't they find ways to encourage developers to adopt the new style?

That isn't the job of the standard.  The standard tries hard not to dictate style.

 

 

 

Why should we continue to suggest that programmers use C arrays if we have a replacement that is better on all accounts except for a few backwards compatible edge cases?

Who says we should suggest programmers use C arrays?  Quit making straw man arguments.

Throwing a compiler warning is a great way to suggest someone not use something.

Then go bug your compiler vendor to do that.  I suspect they won't, for the reasons mentioned here.  

 

Not doing so makes it seem like fair game. I don't know about you, but I'd love for my compiler to find all of these instances for me so that I can fix them.

Fix implies something is broken.

 

 

 

Its already terrible that we have 2 different fixed size array types and we have to teach new programmers the differences between them. Even worse that the most natural syntax is for the one that should be avoided. This kind of legacy cruft is what makes people run screaming to other languages.

"legacy" is a two-edged sword.  It's a major reason people move to C++, and a major reason for many of the whines.  I fail to see any evidence that gratuitously breaking backwards compatibility will *retain* C++ developers.

Nothing is breaking backwards compatibility. I'm not suggesting C arrays ever get removed from the standard, doing such would break C compatibility.

Really?  Deprecated is defined in the standard [depr] as "These are deprecated features, where deprecated  is defined as: Normative for the current edition of the

Standard, but having been identified as a candidate for removal from future revisions."  

 

Instead I'm suggesting discouraging their use to only the cases where they are really needed, which is extern "C" code. Maybe depreciated is too strong a word here, perhaps "discouraged" is better.

Not the job of the standard.

 

Discouraging the use of C arrays from modern C++ would also mean that library writers can stop needing to write special cases for arrays and decaying in their template interfaces.

If their customers demand it, I'm pretty sure most library writers will provide it, whether or not the standard "discourages" it.  strstream is the poster child for this.

You think it is a great idea to gratuituously make it harder for C programmers to move to C++.  I think that is a horrible idea.

For instance, disallowing implicit decay to pointer would break (as in you got to change your code) most usages of C-string literals.  How does that encourage anybody to use C++?

-- 

[Edward Catmur]

Couldn't we get most of the way just with some improvements to the library? For example:

First, require that std::array representation actually contain an array T[N] (except for N=0), and make this accessible, by changing the data member function to T (&data())[N] (again unless N=0):

T (&data())[N];

const T (&data() const)[N];

Next, provide a std::make_array function, in four variants:

template<class T, size_t N> array<T, N> make_array(T (&)[N]);

template<class T, size_t N, class InputIt> array<T, N> make_array(InputIt);

template<class T> array<T, 0> make_array();

template<class T, class... Ts> array<T, 1 + sizeof...(Ts)> make_array(T, Ts...);

This gives improved interoperability and unknown bound deduction, without having to bless a library type into core.

Regards, Ed

[Geoffrey Romer]

On Thu, Apr 24, 2014 at 1:04 AM, Edward Catmur <e...@catmur.co.uk> wrote:

Couldn't we get most of the way just with some improvements to the library? For example:

First, require that std::array representation actually contain an array T[N] (except for N=0), and make this accessible, by changing the data member function to T (&data())[N] (again unless N=0):

T (&data())[N];

const T (&data() const)[N];

Next, provide a std::make_array function, in four variants:

template<class T, size_t N> array<T, N> make_array(T (&)[N]);

template<class T, size_t N, class InputIt> array<T, N> make_array(InputIt);

template<class T> array<T, 0> make_array();

template<class T, class... Ts> array<T, 1 + sizeof...(Ts)> make_array(T, Ts...);

N3824 has already proposed pretty much exactly this. It doesn't have the iterator overload, but that overload is problematic in a lot of ways, and seems superfluous to the goals of array interoperability and bound deduction, so I don't see a need to add it.

 

This gives improved interoperability and unknown bound deduction, without having to bless a library type into core.

Regards, Ed

--

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

[Edward Catmur]

On Thursday, 24 April 2014 16:49:46 UTC+1, Geoffrey Romer wrote:

On Thu, Apr 24, 2014 at 1:04 AM, Edward Catmur <e...@catmur.co.uk> wrote:

Couldn't we get most of the way just with some improvements to the library? For example:

First, require that std::array representation actually contain an array T[N] (except for N=0), and make this accessible, by changing the data member function to T (&data())[N] (again unless N=0):

T (&data())[N];

const T (&data() const)[N];

 

Wondering - do you know whether this has previously been proposed, or indeed why C++11 std::array does not have array typed member access?

 

Next, provide a std::make_array function, in four variants:

template<class T, size_t N> array<T, N> make_array(T (&)[N]);

template<class T, size_t N, class InputIt> array<T, N> make_array(InputIt);

template<class T> array<T, 0> make_array();

template<class T, class... Ts> array<T, 1 + sizeof...(Ts)> make_array(T, Ts...);

N3824 has already proposed pretty much exactly this. It doesn't have the iterator overload, but that overload is problematic in a lot of ways, and seems superfluous to the goals of array interoperability and bound deduction, so I don't see a need to add it.

Adding an iterator overload enables construction from vector and from array slices, where otherwise the temptation would be to use a cast to array type. I agree it's not strictly necessary.

[Geoffrey Romer]

On Thu, Apr 24, 2014 at 9:32 AM, Edward Catmur <e...@catmur.co.uk> wrote:

On Thursday, 24 April 2014 16:49:46 UTC+1, Geoffrey Romer wrote:

On Thu, Apr 24, 2014 at 1:04 AM, Edward Catmur <e...@catmur.co.uk> wrote:

Couldn't we get most of the way just with some improvements to the library? For example:

First, require that std::array representation actually contain an array T[N] (except for N=0), and make this accessible, by changing the data member function to T (&data())[N] (again unless N=0):

T (&data())[N];

const T (&data() const)[N];

 

Wondering - do you know whether this has previously been proposed, or indeed why C++11 std::array does not have array typed member access?

I don't know, but my guess is that it's because data() would have to be SFINAEd out in the N=0 case, which complicates the API, and could greatly complicate user code that manipulates arrays generically. Which, now that I think about it, pretty much sinks this part of your proposal; it would probably break too much existing code. However, it seems like it would be feasible to provide a separate member function that returns an array reference.

[Olaf van der Spek]

On Monday, April 21, 2014 5:50:34 AM UTC+2, David Krauss wrote:

I think std::array_view is supposed to be the general solution, no?

array_view isn't fixed-size, so it's not a direct replacement for a function taking uint8_t[20] or so. For non-fixed-size inputs array_view seems like the perfect solution.