------=_Part_2712_9272465.1397977724110
Content-Type: text/plain; charset=UTF-8

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.

--

---
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_2712_9272465.1397977724110
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We propose the following two new standard conversions:<div=
><br></div><div><div>&nbsp; &nbsp; 1. A value of type "derived-declarator-t=
ype-list array of N T" of value category VC can be converted to a value of =
type "derived-declarator-type-list std::array&lt;T,N&gt;" of value category=
 VC.</div><div><div>&nbsp; &nbsp; 2. A value of type "derived-declarator-ty=
pe-list std::array&lt;T,N&gt;" of value category VC can be converted to a v=
alue of type "derived-declarator-type-list array of N T" of value category =
VC.</div><div><br></div><div><div>It isn't 100% clear whether the two famil=
ies of types are required to have identical representations, but in practic=
e they surely do (don't they?). &nbsp;The conversion is therefore simply a =
static substitution of the types.</div></div><div><br></div><div>We also pr=
opose the introduction of initialization of built-in array types by values =
of built-in array types. &nbsp;For initialization of arrays of unknown boun=
d, the bound is inferred by the initializer as you would expect. &nbsp;This=
 doesn't break compatibility with C, because this is ill-formed in C.</div>=
<div><br></div><div>This would allow the following for example:</div><div><=
br></div><div>&nbsp; &nbsp; int x[] =3D {1, 2, 3};</div><div>&nbsp; &nbsp; =
int y[] =3D x;</div><div>&nbsp; &nbsp; std::array&lt;int,3&gt; z =3D x;</di=
v><div>&nbsp; &nbsp; int w[] =3D z;</div><div><br></div><div>&nbsp; &nbsp; =
std::array&lt;int, 3&gt; times2(std::array&lt;int, 3&gt; A)<br></div><div>&=
nbsp; &nbsp; {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; for (auto&amp; a : A)<=
/div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;a *=3D 2;</div><div><br>=
</div><div>&nbsp; &nbsp; &nbsp; &nbsp; return A;</div><div>&nbsp; &nbsp; }<=
br></div><div><br></div><div>&nbsp; &nbsp; int t[] =3D times2(w);<br></div>=
<div><br></div><div>It essentially means std::array and array types are com=
pletely interchangeable, and become almost the same type. &nbsp;std::array =
remains necessary for the original purpose it was introduced, to specify re=
turn types and parameter types as arrays, because for backward compatibilit=
y with C built-in array types in such positions essentially become pointers=
.. &nbsp;For the remainder we become free to use the nicer built-in array de=
clarator and unknown bound rules. &nbsp;We might also effectively get all t=
he member functions of std::array on builtin arrays:<br></div><div><br></di=
v><div>&nbsp; &nbsp; int u[] =3D {42, 43};</div><div>&nbsp; &nbsp; int v =
=3D u.front(); // v =3D 42</div><div><br></div><div>Feedback on this idea a=
ppreciated.</div><div>&nbsp; &nbsp;-Andrew.</div><div><br></div><div></div>=
</div><div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2712_9272465.1397977724110--

.

Em dom 20 abr 2014, =E0s 00:08:44, Andrew Tomazos escreveu:
> We propose the following two new standard conversions:
>=20
>     1. A value of type "derived-declarator-type-list array of N T" of val=
ue=20
> 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=
=20
> value category VC can be converted to a value of type=20
> "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?=
=20
I.e., please give me the underlying tools instead of writing "std::array" i=
n=20
the spec.

--=20
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

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

--Apple-Mail=_3528EB2A-CA3E-473D-8486-4BC1EDA11752
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


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

> Em dom 20 abr 2014, =E0s 00:08:44, Andrew Tomazos escreveu:
>> We propose the following two new standard conversions:
>>=20
>>    1. A value of type "derived-declarator-type-list array of N T" of val=
ue=20
>> 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=
=20
>> value category VC can be converted to a value of type=20
>> "derived-declarator-type-list array of N T" of value category VC.
>=20
> Can you specify this in such a way I can do the same for QVarLengthArray?=
=20
> I.e., please give me the underlying tools instead of writing "std::array"=
 in=20
> 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 occasio=
nally used meta-variable, but it has no single definition per se. Perhaps i=
t was a grammar production in pre-standard drafts.

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_3528EB2A-CA3E-473D-8486-4BC1EDA11752
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html=
 charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/=
html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-wor=
d; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><d=
iv><div>On 2014&ndash;04&ndash;21, at 2:44 AM, Thiago Macieira &lt;<a href=
=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Em dom 20 ab=
r 2014, =E0s 00:08:44, Andrew Tomazos escreveu:<br><blockquote type=3D"cite=
">We propose the following two new standard conversions:<br><br> &nbsp;&nbs=
p;&nbsp;1. A value of type "derived-declarator-type-list array of N T" of v=
alue <br>category VC can be converted to a value of type<br>"derived-declar=
ator-type-list std::array&lt;T,N&gt;" of value category VC.<br> &nbsp;&nbsp=
;&nbsp;2. A value of type "derived-declarator-type-list std::array&lt;T,N&g=
t;" of <br>value category VC can be converted to a value of type <br>"deriv=
ed-declarator-type-list array of N T" of value category VC.<br></blockquote=
><br>Can you specify this in such a way I can do the same for QVarLengthArr=
ay? <br>I.e., please give me the underlying tools instead of writing "std::=
array" in <br>the spec.<br></blockquote></div><br><div>I think <font face=
=3D"Courier">std::array_view</font> is supposed to be the general solution,=
 no?</div><div><br></div><div>These conversions seem way more trouble than =
they&rsquo;re worth, given that. For one thing, user specializations would =
have to be disallowed.</div><div><br></div><div>By the way, what is derived=
-declarator-type-list? It seems to be an occasionally used meta-variable, b=
ut it has no single definition per se. Perhaps it was a grammar production =
in pre-standard drafts.</div><div><br></div></body></html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--Apple-Mail=_3528EB2A-CA3E-473D-8486-4BC1EDA11752--

.

------=_Part_3588_26315769.1398060435740
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

These conversions seem way more trouble than they=E2=80=99re worth, given t=
hat. For=20
> one thing, user specializations would have to be disallowed.
>

User specializations of what?  And why would they have to be disallowed?=20
 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=20
> occasionally used meta-variable, but it has no single definition per se.=
=20
> Perhaps it was a grammar production in pre-standard drafts.
>

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

    int (* const & x) [10] =3D ...;
    std::array<int, 10>* const & y =3D x; // ok

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_3588_26315769.1398060435740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 21, 2014 5:50:34 AM UTC+2, David Krauss w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div>I think <font face=3D"Courier">std::array_view</font> is su=
pposed to be the general solution, no?</div></div></blockquote><div>&nbsp;<=
/div><div>The general solution to what? &nbsp;std::string_view and std::arr=
ay_view provide a non-owning reference type to a subsequence of a string-li=
ke or array-like container. &nbsp;It isn't clear what relevance they have t=
o this proposal. &nbsp;The purpose of this proposal is to bring parity betw=
een built-in array types and std::array. &nbsp;It is a kind of simplificati=
on.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div s=
tyle=3D"word-wrap:break-word"><div></div><div>These conversions seem way mo=
re trouble than they=E2=80=99re worth, given that. For one thing, user spec=
ializations would have to be disallowed.</div></div></blockquote><div><br><=
/div><div>User specializations of what? &nbsp;And why would they have to be=
 disallowed? &nbsp;And what are the other things apart from this "one thing=
"?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div st=
yle=3D"word-wrap:break-word"><div></div><div>By the way, what is derived-de=
clarator-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.</div></div></blockquote><div><br></div><div>It just me=
ans some (possibly empty) prefix of compound type declarators. &nbsp;For ex=
ample "reference to const pointer to":</div><div><br></div><div>&nbsp; &nbs=
p; int (* const &amp; x) [10] =3D ...;</div><div>&nbsp; &nbsp; std::array&l=
t;int, 10&gt;* const &amp; y =3D x; // ok</div><div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3588_26315769.1398060435740--

.

--Apple-Mail=_EF29CE88-D4F4-48CE-9E69-E46D0AF8EC95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-04-21, at 2:07 PM, Andrew Tomazos <andrewtomazos@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?
> =20
> The general solution to what?  std::string_view and std::array_view provi=
de a non-owning reference type to a subsequence of a string-like or array-l=
ike 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 type=
s 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. I=
f array_view has an implicit conversion function to array, then the user ma=
y 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. F=
or one thing, user specializations would have to be disallowed.
>=20
> 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 ha=
ve) the same representation and lifetime semantics as the naked array, need=
ed to make the conversion work.

The proposal seems to be essentially about changing the lifetime of an obje=
ct in-flight, which may get messy in the object lifetime model. I'm not rea=
lly sure what is the use for changing type and ownership simultaneously, th=
ough, as opposed to just providing a non-owning view.

> By the way, what is derived-declarator-type-list? It seems to be an occas=
ionally used meta-variable, but it has no single definition per se. Perhaps=
 it was a grammar production in pre-standard drafts.
>=20
> It just means some (possibly empty) prefix of compound type declarators. =
 For example "reference to const pointer to":
>=20
>     int (* const & x) [10] =3D ...;
>     std::array<int, 10>* const & y =3D x; // ok

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

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

--=20

---=20
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 e=
mail 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-proposa=
ls/.

--Apple-Mail=_EF29CE88-D4F4-48CE-9E69-E46D0AF8EC95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;04&ndash;21, at 2:07 PM, Andrew Tomazos &lt;<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">On Mo=
nday, April 21, 2014 5:50:34 AM UTC+2, David Krauss wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">I think <fo=
nt face=3D"Courier">std::array_view</font> is supposed to be the general so=
lution, no?</div></blockquote><div>&nbsp;</div><div>The general solution to=
 what? &nbsp;std::string_view and std::array_view provide a non-owning refe=
rence type to a subsequence of a string-like or array-like container. &nbsp=
;It isn't clear what relevance they have to this proposal. &nbsp;The purpos=
e of this proposal is to bring parity between built-in array types and std:=
:array. &nbsp;It is a kind of simplification.</div></div></blockquote><div>=
<br></div><div>If you are writing an interface that needs that conversion, =
have it take an <font face=3D"Courier">array_view</font> instead. If it&rsq=
uo;s owning a copy, it needs a <font face=3D"Courier">std::array</font> any=
way. If <font face=3D"Courier">array_view</font> has an implicit conversion=
 function to <font face=3D"Courier">array</font>, then the user may idiomat=
ically pass <font face=3D"Courier">array_view</font>&nbsp;&ldquo;by value&r=
dquo; without caring about ownership. Such a conversion doesn&rsquo;t requi=
re changing the core language.</div><br><blockquote type=3D"cite"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wr=
ap:break-word"><div></div><div>These conversions seem way more trouble than=
 they&rsquo;re worth, given that. For one thing, user specializations would=
 have to be disallowed.</div></div></blockquote><div><br></div><div>User sp=
ecializations of what? &nbsp;And why would they have to be disallowed? &nbs=
p;And what are the other things apart from this "one thing&rdquo;?</div></d=
iv></blockquote><div><br></div><div>User specializations of std::array don&=
rsquo;t need to have (and usually won&rsquo;t have) the same representation=
 and lifetime semantics as the naked array, needed to make the conversion w=
ork.</div><div><br></div><div>The proposal seems to be essentially about ch=
anging the lifetime of an object in-flight, which may get messy in the obje=
ct lifetime model. I&rsquo;m not really sure what is the use for changing t=
ype and ownership simultaneously, though, as opposed to just providing a no=
n-owning view.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-w=
idth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid;=
 padding-left: 1ex; position: static; z-index: auto;"><div style=3D"word-wr=
ap:break-word"><div></div><div>By the way, what is derived-declarator-type-=
list? It seems to be an occasionally used meta-variable, but it has no sing=
le definition per se. Perhaps it was a grammar production in pre-standard d=
rafts.</div></div></blockquote><div><br></div><div>It just means some (poss=
ibly empty) prefix of compound type declarators. &nbsp;For example "referen=
ce to const pointer to":</div><div><br></div><div>&nbsp; &nbsp; int (* cons=
t &amp; x) [10] =3D ...;</div><div>&nbsp; &nbsp; std::array&lt;int, 10&gt;*=
 const &amp; y =3D x; // ok</div></div></blockquote><div><br></div><div>I s=
ee. This is like the qualification conversion rule, in that it works at any=
 level and not only the &ldquo;top.&rdquo;&nbsp;</div><div><br></div><div>U=
nlike other standard conversions, you would also want to apply it recursive=
ly, to handle multidimensional arrays.</div><div><br></div></div></body></h=
tml>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--Apple-Mail=_EF29CE88-D4F4-48CE-9E69-E46D0AF8EC95--

.

On 2014-04-21, at 3:21 PM, David Krauss <potswa@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?

--

---
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_2140_9799912.1398078862415
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, April 21, 2014 12:09:44 PM UTC+2, David Krauss wrote:
>
> On 2014=E2=80=9304=E2=80=9321, at 3:21 PM, David Krauss <pot...@gmail.com=
 <javascript:>>=20
> wrote:=20
>
> > The proposal seems to be essentially about changing the lifetime of an=
=20
> object in-flight=20
>
> Oops, changing the *type* of an object in-flight. It looks like you would=
=20
> want to be able to destroy the object through a converted expression, is=
=20
> that right?=20
>

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

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_2140_9799912.1398078862415
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 21, 2014 12:09:44 PM UTC+2, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014=E2=80=9304=E2=80=
=9321, at 3:21 PM, David Krauss &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"cUbvgaMW-_wJ" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">po=
t...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; The proposal seems to be essentially about changing the lifetime o=
f an object in-flight
<br>
<br>Oops, changing the *type* of an object in-flight. It looks like you wou=
ld want to be able to destroy the object through a converted expression, is=
 that right?
<br></blockquote><div><br></div><div>I don't really follow what you are say=
ing. &nbsp;Can you give a code example of the type of an object changing "i=
n-flight" due to the conversion?</div><div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2140_9799912.1398078862415--

.

------=_Part_433_9576424.1398278979782
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

std::array<std::array<int, 5>, 10> a; is ugly as hell, its really the only=
=20
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]];=20
int[10][5] x;

Arrays of unknown bound with explicit type
int x[{}] =3D {1, 3, 4}; //becomes std::array<int, 3> =3D {1, 3, 4};
int x[[]] =3D { 1, 3, 4};
int[] x =3D { 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=20
std::array
auto x[] =3D { 1, 2, 3 }; //becomes std::array<int, 3> =3D {1, 2, 3};
auto x[{}] =3D { 1, 2, 3};
auto x[[]] =3D { 1, 2, 3};
auto[] x =3D { 1, 2, 3};

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





On Monday, April 21, 2014 7:14:22 AM UTC-4, Andrew Tomazos wrote:
>
> On Monday, April 21, 2014 12:09:44 PM UTC+2, David Krauss wrote:
>>
>> On 2014=E2=80=9304=E2=80=9321, at 3:21 PM, David Krauss <pot...@gmail.co=
m> wrote:=20
>>
>> > The proposal seems to be essentially about changing the lifetime of an=
=20
>> object in-flight=20
>>
>> Oops, changing the *type* of an object in-flight. It looks like you woul=
d=20
>> want to be able to destroy the object through a converted expression, is=
=20
>> that right?=20
>>
>
> I don't really follow what you are saying.  Can you give a code example o=
f=20
> the type of an object changing "in-flight" due to the conversion?
>
>

--=20

---=20
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 e=
mail 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-proposa=
ls/.

------=_Part_433_9576424.1398278979782
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'd really like to just see a shorthand for declaring std:=
:array objects, with compiler warnings enabled for declaring now depreciate=
d C arrays. C arrays with their pointer decaying behavior are really annoyi=
ng 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.<br><br>std::array&lt;std::array&lt;int, 5&gt;, 1=
0&gt; a; is ugly as hell, its really the only reason I still use C arrays s=
ometimes.<br><br>Some possibilities for syntax:<br><br>Single dimension arr=
ays with known size<br>int x[{5}];<br>int x[[5]]; //maybe this clashes with=
 attribute syntax?<br>int[5] x;<br><br><br>Multi dimensional arrays<br>int =
x[{10}{5}]; //shorthand for std::array&lt;std::array&lt;int, 5&gt;, 10&gt;<=
br>int x[10,5];<br>int x[[10][5]]; <br>int[10][5] x;<br><br>Arrays of unkno=
wn bound with explicit type<br>int x[{}] =3D {1, 3, 4}; //becomes std::arra=
y&lt;int, 3&gt; =3D {1, 3, 4};<br>int x[[]] =3D { 1, 3, 4};<br>int[] x =3D =
{ 1, 3, 4};<br><br>Arrays of unknown bound with deduced type using auto<br>=
//auto doesn't work for C arrays, so we could use auto with [] for std::arr=
ay<br>auto x[] =3D { 1, 2, 3 }; //becomes std::array&lt;int, 3&gt; =3D {1, =
2, 3};<br>auto x[{}] =3D { 1, 2, 3};<br>auto x[[]] =3D { 1, 2, 3};<br>auto[=
] x =3D { 1, 2, 3};<br><br>auto x[] =3D { 1, 2L, 3}; //compiler error, cann=
ot deduce the type<br><br><br><br><br><br>On Monday, April 21, 2014 7:14:22=
 AM UTC-4, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr">On Monday, April 21, 2014 12:09:44 PM UTC+2, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">On 2014=E2=80=9304=E2=80=93=
21, at 3:21 PM, David Krauss &lt;<a>pot...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; The proposal seems to be essentially about changing the lifetime o=
f an object in-flight
<br>
<br>Oops, changing the *type* of an object in-flight. It looks like you wou=
ld want to be able to destroy the object through a converted expression, is=
 that right?
<br></blockquote><div><br></div><div>I don't really follow what you are say=
ing. &nbsp;Can you give a code example of the type of an object changing "i=
n-flight" due to the conversion?</div><div><br></div></div></blockquote></d=
iv>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_433_9576424.1398278979782--

.

--e89a8f3baa079918e004f7ba4a09
Content-Type: text/plain; charset=UTF-8

On 20 April 2014 02:08, Andrew Tomazos <andrewtomazos@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:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--e89a8f3baa079918e004f7ba4a09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 20 April 2014 02:08, Andrew Tomazos <span dir=3D"ltr">&=
lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomaz=
os@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">We propose the following tw=
o new standard conversions:<div><br></div><div><div>=C2=A0 =C2=A0 1. A valu=
e of type &quot;derived-declarator-type-list array of N T&quot; of value ca=
tegory VC can be converted to a value of type &quot;derived-declarator-type=
-list std::array&lt;T,N&gt;&quot; of value category VC.</div>

<div><div>=C2=A0 =C2=A0 2. A value of type &quot;derived-declarator-type-li=
st std::array&lt;T,N&gt;&quot; of value category VC can be converted to a v=
alue of type &quot;derived-declarator-type-list array of N T&quot; of value=
 category VC.</div>

</div></div></div></blockquote><div><br></div><div>What about aliasing rule=
s?</div><div><br></div><div>If I have:</div><div><br></div><div>template&lt=
;size_t N&gt;</div><div>void foo(int(&amp;a)[N], std::array&lt;int, N&gt;&a=
mp; b)</div>

<div><br></div><div>does the compiler have to now assume a may be an alias =
for b?</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--e89a8f3baa079918e004f7ba4a09--

.

--047d7bacb40e2da15804f7ba5511
Content-Type: text/plain; charset=UTF-8

On 23 April 2014 13:49, Matthew Fioravante <fmatthew5876@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.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--047d7bacb40e2da15804f7ba5511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 23 April 2014 13:49, Matthew Fioravante <span dir=3D"lt=
r">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew=
5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;d really like to just=
 see a shorthand for declaring std::array objects, with compiler warnings e=
nabled for declaring now depreciated C arrays. </div>

</blockquote><div><br></div><div>C arrays are not deprecated.</div></div>--=
 <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=
=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--047d7bacb40e2da15804f7ba5511--

.

------=_Part_551_26479757.1398281238806
Content-Type: text/plain; charset=UTF-8


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

On Wednesday, April 23, 2014 2:58:51 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 23 April 2014 13:49, Matthew Fioravante <fmatth...@gmail.com<javascript:>
> > 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.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

---
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_551_26479757.1398281238806
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>I meant that they would be depreciated after the new s=
yntax becomes available.<br><br>On Wednesday, April 23, 2014 2:58:51 PM UTC=
-4, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">On 23 April 2014 13:49, Matthew Fioravante <span dir=3D"ltr"=
>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"8-B=
htOtT3OoJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a>&gt;</sp=
an> wrote:<br><div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I'd really like to just see=
 a shorthand for declaring std::array objects, with compiler warnings enabl=
ed for declaring now depreciated C arrays. </div>

</blockquote><div><br></div><div>C arrays are not deprecated.</div></div>--=
 <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"8-BhtOtT3OoJ" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
 true;">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_551_26479757.1398281238806--

.

--e89a8f3baa07dbd63f04f7bac90c
Content-Type: text/plain; charset=UTF-8

On 23 April 2014 14:27, Matthew Fioravante <fmatthew5876@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??
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--e89a8f3baa07dbd63f04f7bac90c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 23 April 2014 14:27, Matthew Fioravante <span dir=3D"lt=
r">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew=
5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I meant that they would=
 be depreciated after the new syntax becomes available.<br></div></blockquo=
te>

<div><br></div><div>We should deprecated a huge body of currently working c=
ode, as well as C compatibility? =C2=A0Why??</div></div>-- <br>=C2=A0Nevin =
&quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord=
..com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--e89a8f3baa07dbd63f04f7bac90c--

.

Il giorno 23/apr/2014, alle ore 20:49, Matthew Fioravante <fmatthew5876@gma=
il.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 a=
rrays with their pointer decaying behavior are really annoying to use and h=
ave 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 com=
patibility.
>=20
> std::array<std::array<int, 5>, 10> a; is ugly as hell, its really the onl=
y 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 =3D T;
};

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

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

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


Bye,
Nicola

--=20

---=20
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 e=
mail 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-proposa=
ls/.

.

------=_Part_6437_3491424.1398284767542
Content-Type: text/plain; charset=UTF-8


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.

On Wednesday, April 23, 2014 3:31:29 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 23 April 2014 14:27, Matthew Fioravante <fmatth...@gmail.com<javascript:>
> > 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??
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

---
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_6437_3491424.1398284767542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Other than maintaining C compatibility, the ugly synta=
x 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 sugg=
est that programmers use C arrays if we have a replacement that is better o=
n all accounts except for a few backwards compatible edge cases?<br><br>Its=
 already terrible that we have 2 different fixed size array types and we ha=
ve to teach new programmers the differences between them. Even worse that t=
he 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.<br><br>=
On Wednesday, April 23, 2014 3:31:29 PM UTC-4, Nevin ":-)" Liber wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On 23 April 2014 =
14:27, Matthew Fioravante <span dir=3D"ltr">&lt;<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"JTkt-mV0FWgJ" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">fmatth...@gmail.com</a>&gt;</span> wrote:<br><div><div class=3D"g=
mail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I meant that they would=
 be depreciated after the new syntax becomes available.<br></div></blockquo=
te>

<div><br></div><div>We should deprecated a huge body of currently working c=
ode, as well as C compatibility? &nbsp;Why??</div></div>-- <br>&nbsp;Nevin =
":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"JTkt-mV0FWgJ" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">ne...@evi=
loverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6437_3491424.1398284767542--

.

------=_Part_565_2127454.1398285534826
Content-Type: text/plain; charset=UTF-8



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.

--

---
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_565_2127454.1398285534826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, April 23, 2014 4:09:18 PM UTC-4, Nic=
ola Gigante wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You don'=
t need a language extension to simplify it:
<br>
<br>#include &lt;type_traits&gt;
<br>#include &lt;array&gt;
<br>
<br>template&lt;typename T&gt;
<br>class convert_array {
<br>public:
<br>&nbsp; &nbsp; using type =3D T;
<br>};
<br>
<br>template&lt;typename T, size_t N&gt;
<br>class convert_array&lt;T[N]&gt;
<br>{
<br>public:
<br>&nbsp; &nbsp; using type =3D std::array&lt;typename convert_array&lt;T&=
gt;::type, N&gt;;
<br>};
<br>
<br>template&lt;typename T&gt;
<br>using array =3D typename convert_array&lt;T&gt;::type;
<br>
<br>int main()
<br>{
<br>&nbsp; &nbsp; array&lt;int[2][3]&gt; matrix3d;
<br>&nbsp; &nbsp;=20
<br>&nbsp; &nbsp; matrix3d[1][2] =3D 42;
<br>&nbsp; &nbsp;=20
<br>&nbsp; &nbsp; return 0;
<br>}
<br>
<br>
<br>Bye,
<br>Nicola</blockquote><div><br>That's elegant, but it doesn't work with un=
bounded initialization.<br><br>I can't say array&lt;int[]&gt; =3D { 1, 2, 3=
};<br><br>That requires a language extension. Either a special case for arr=
ay syntax, or a new proposal for constexpr constructors which can deduce te=
mplate arguments from constructor arguments. <br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_565_2127454.1398285534826--

.

--e89a8f3baa0797ffdb04f7bbbbf7
Content-Type: text/plain; charset=UTF-8

On 23 April 2014 15:26, Matthew Fioravante <fmatthew5876@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.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--e89a8f3baa0797ffdb04f7bbbbf7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 23 April 2014 15:26, Matthew Fioravante <span dir=3D"lt=
r">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew=
5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Other than maintaining =
C compatibility, the ugly syntax of std::array, and unbounded initializatio=
n. Can you name one reason why someone should prefer to still use C arrays?=
 </div>

</blockquote><div><br></div><div>Backwards compatibility. =C2=A0Why should =
I change millions of lines of working code just because *you* want to depre=
cate this?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Why should we continue to suggest that programmers use C a=
rrays if we have a replacement that is better on all accounts except for a =
few backwards compatible edge cases?<br></div></blockquote><div><br></div>

<div>Who says we should suggest programmers use C arrays? =C2=A0Quit making=
 straw man arguments.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">

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 tha=
t 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.<br>

</div></blockquote><div><br></div></div><div>&quot;legacy&quot; is a two-ed=
ged sword. =C2=A0It&#39;s a major reason people move to C++, and a major re=
ason for many of the whines. =C2=A0I fail to see any evidence that gratuito=
usly breaking backwards compatibility will *retain* C++ developers.</div>

-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--e89a8f3baa0797ffdb04f7bbbbf7--

.

--001a11c3d864da1ca504f7bc105a
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 23, 2014 at 2:49 PM, Matthew Fioravante
<fmatthew5876@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?

--

---
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/.

--001a11c3d864da1ca504f7bc105a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Apr 23, 2014 at 2:49 PM, Matthew Fioravante <span dir=3D"lt=
r">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew=
5876@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;d really like to just=
 see a shorthand for declaring std::array objects, with compiler warnings e=
nabled for declaring now depreciated C arrays. C arrays with their pointer =
decaying behavior are really annoying to use and have a lot of pitfalls. Ar=
rays should be separate types with value semantics like everything else in =
C++. The only use I could see for C array is C compatibility.<br>
<br>std::array&lt;std::array&lt;int, 5&gt;, 10&gt; a; is ugly as hell, its =
really the only reason I still use C arrays sometimes.<br><br>Some possibil=
ities for syntax:<br><br>Single dimension arrays with known size<br>int x[{=
5}];<br>
int x[[5]]; //maybe this clashes with attribute syntax?<br>int[5] x;<br><br=
></div></blockquote><div><br></div><div>int[5] x;=C2=A0 for sure.<br><br></=
div></div>I&#39;m not even sure what I think about the entire proposal, but=
 if we had new array syntax, this should be it.=C2=A0 I wish it worked with=
 current arrays.=C2=A0 If it was reserved for value-type non-decaying array=
s, that would be great.<br>
<br>But what about unnamed function params:<br><br></div><div class=3D"gmai=
l_extra">void f(int [5] );<br><br></div><div class=3D"gmail_extra">could th=
at mean either array type?<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11c3d864da1ca504f7bc105a--

.

------=_Part_6321_18895524.1398287147389
Content-Type: text/plain; charset=UTF-8


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<javascript:>
> > 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 <javascript:>>  (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.


--

---
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_6321_18895524.1398287147389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, April 23, 2014 4:39:05 PM UTC-4, Nevin "=
:-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On 23 April 2014 15:26, Matthew Fioravante <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"aJ4EcB8Xg3IJ" =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">fmatth...@gmail.com</a>&gt;</span> wrote:<br=
><div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Other than maintaining =
C compatibility, the ugly syntax of std::array, and unbounded initializatio=
n. Can you name one reason why someone should prefer to still use C arrays?=
 </div>

</blockquote><div><br></div><div>Backwards compatibility. &nbsp;Why should =
I change millions of lines of working code just because *you* want to depre=
cate this?</div></div></div></div></blockquote><div><br>Lets not make this =
personal. Nobody is doing anything for me or for anyone else. If the C++ co=
mmunity generally agrees that std::array is a better construct than C array=
s, why shouldn't they find ways to encourage developers to adopt the new st=
yle?<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div dir=3D"ltr">Why should we continue to suggest that programmers use C a=
rrays if we have a replacement that is better on all accounts except for a =
few backwards compatible edge cases?<br></div></blockquote><div><br></div>

<div>Who says we should suggest programmers use C arrays? &nbsp;Quit making=
 straw man arguments.</div></div></div></div></blockquote><div><br>Throwing=
 a compiler warning is a great way to suggest someone not use something. No=
t doing so makes it seem like fair game. I don't know about you, but I'd lo=
ve for my compiler to find all of these instances for me so that I can fix =
them.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">

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 tha=
t 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.<br>

</div></blockquote><div><br></div></div><div>"legacy" is a two-edged sword.=
 &nbsp;It's a major reason people move to C++, and a major reason for many =
of the whines. &nbsp;I fail to see any evidence that gratuitously breaking =
backwards compatibility will *retain* C++ developers.</div></div></div></bl=
ockquote><div><br>Nothing is breaking backwards compatibility. I'm not sugg=
esting 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 depreci=
ated is too strong a word here, perhaps "discouraged" is better.<br><br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>

-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"aJ4EcB8Xg3IJ" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div></blockquote><div><br>Discouraging the use of C arrays from mod=
ern C++ would also mean that library writers can stop needing to write spec=
ial cases for arrays and decaying in their template interfaces.<br>&nbsp;</=
div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6321_18895524.1398287147389--

.

--e89a8f3baa07ee8af304f7bcada1
Content-Type: text/plain; charset=UTF-8

On 23 April 2014 16:05, Matthew Fioravante <fmatthew5876@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++?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--e89a8f3baa07ee8af304f7bcada1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 23 April 2014 16:05, Matthew Fioravante <span dir=3D"lt=
r">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew=
5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><div>If the C++ community generally a=
grees that std::array is a better construct than C arrays, why shouldn&#39;=
t they find ways to encourage developers to adopt the new style?<br>

</div></div></blockquote><div><br></div><div>That isn&#39;t the job of the =
standard. =C2=A0The standard tries hard not to dictate style.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">

<div dir=3D"ltr"><div></div><div class=3D""><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr">

<div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr">Why should we continue to suggest that programmers use C a=
rrays if we have a replacement that is better on all accounts except for a =
few backwards compatible edge cases?<br></div></blockquote><div><br></div>



<div>Who says we should suggest programmers use C arrays? =C2=A0Quit making=
 straw man arguments.</div></div></div></div></blockquote></div><div><br>Th=
rowing a compiler warning is a great way to suggest someone not use somethi=
ng.</div>

</div></blockquote><div><br></div><div>Then go bug your compiler vendor to =
do that. =C2=A0I suspect they won&#39;t, for the reasons mentioned here. =
=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div> Not doing so makes it seem like fair game. I don&#39=
;t know about you, but I&#39;d love for my compiler to find all of these in=
stances for me so that I can fix them.<br></div></div></blockquote><div>
<br>
</div><div>Fix implies something is broken.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex">

<div dir=3D"ltr"><div>=C2=A0</div><div class=3D""><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div>

<div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r">

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 tha=
t 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.<br>



</div></blockquote><div><br></div></div><div>&quot;legacy&quot; is a two-ed=
ged sword. =C2=A0It&#39;s a major reason people move to C++, and a major re=
ason for many of the whines. =C2=A0I fail to see any evidence that gratuito=
usly breaking backwards compatibility will *retain* C++ developers.</div>

</div></div></blockquote></div><div><br>Nothing is breaking backwards compa=
tibility. I&#39;m not suggesting C arrays ever get removed from the standar=
d, doing such would break C compatibility.</div></div></blockquote><div>

<br></div><div>Really? =C2=A0Deprecated is defined in the standard [depr] a=
s &quot;<span style=3D"font-family:Helvetica;font-size:10px">These are depr=
ecated features, where deprecated</span><span style=3D"font-family:Helvetic=
a;font-size:10px">=C2=A0 </span><span style=3D"font-family:Helvetica;font-s=
ize:10px">is defined as: Normative for the current edition of the</span></d=
iv>


<p style=3D"margin:0px"><span style=3D"font-family:Helvetica;font-size:10px=
">Standard, but having been identified as a candidate for removal from futu=
re revisions.&quot; =C2=A0</span></p><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div> Instead I&#39;m suggesting discouraging their use to=
 only the cases where they are really needed, which is extern &quot;C&quot;=
 code. Maybe depreciated is too strong a word here, perhaps &quot;discourag=
ed&quot; is better.<br>

</div></div></blockquote><div><br></div><div>Not the job of the standard.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex">

<div dir=3D"ltr"><div>Discouraging the use of C arrays from modern C++ woul=
d also mean that library writers can stop needing to write special cases fo=
r arrays and decaying in their template interfaces.<br></div></div></blockq=
uote>

<div><br></div><div>If their customers demand it, I&#39;m pretty sure most =
library writers will provide it, whether or not the standard &quot;discoura=
ges&quot; it. =C2=A0strstream is the poster child for this.</div><div><br><=
/div>

<div>You think it is a great idea to gratuituously make it harder for C pro=
grammers to move to C++. =C2=A0I think that is a horrible idea.</div><div><=
br></div><div>For instance, disallowing implicit decay to pointer would bre=
ak (as in you got to change your code) most usages of C-string literals. =
=C2=A0How does that encourage anybody to use C++?</div>

<div>--=C2=A0<br></div></div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--e89a8f3baa07ee8af304f7bcada1--

.

------=_Part_84_26880031.1398326662344
Content-Type: text/plain; charset=UTF-8

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

--

---
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_84_26880031.1398326662344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Couldn't we get most of the way just with some improvement=
s to the library? For example:<div><br></div><div>First, require that std::=
array representation actually contain an array T[N] (except for N=3D0), and=
 make this accessible, by changing the data member function to T (&amp;data=
())[N] (again unless N=3D0):</div><div><br></div><div><div>T (&amp;data())[=
N];</div></div><div><div>const T (&amp;data() const)[N];</div></div><div><b=
r></div><div>Next, provide a std::make_array function, in four variants:</d=
iv><div><br></div><div><div>template&lt;class T, size_t N&gt; array&lt;T, N=
&gt; make_array(T (&amp;)[N]);</div></div><div><div><div>template&lt;class =
T, size_t N, class InputIt&gt; array&lt;T, N&gt; make_array(InputIt);</div>=
</div></div><div><div><div>template&lt;class T&gt; array&lt;T, 0&gt; make_a=
rray();</div></div></div><div><div>template&lt;class T, class... Ts&gt; arr=
ay&lt;T, 1 + sizeof...(Ts)&gt; make_array(T, Ts...);</div></div><div><br></=
div><div>This gives improved interoperability and unknown bound deduction, =
without having to bless a library type into core.</div><div><br></div><div>=
Regards, Ed</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_84_26880031.1398326662344--

.

--001a1134a21a66780b04f7cbccee
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 24, 2014 at 1:04 AM, Edward Catmur <ed@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 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3824.htm> 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-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/.
>

--

---
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/.

--001a1134a21a66780b04f7cbccee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Apr 24, 2014 at 1:04 AM, Edward Catmur <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Couldn&#39;t we get most of=
 the way just with some improvements to the library? For example:<div><br><=
/div>
<div>First, require that std::array representation actually contain an arra=
y T[N] (except for N=3D0), and make this accessible, by changing the data m=
ember function to T (&amp;data())[N] (again unless N=3D0):</div><div><br></=
div>
<div><div>T (&amp;data())[N];</div></div><div><div>const T (&amp;data() con=
st)[N];</div></div></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">
<div><br></div><div>Next, provide a std::make_array function, in four varia=
nts:</div><div><br></div><div><div>template&lt;class T, size_t N&gt; array&=
lt;T, N&gt; make_array(T (&amp;)[N]);</div></div><div><div><div>template&lt=
;class T, size_t N, class InputIt&gt; array&lt;T, N&gt; make_array(InputIt)=
;</div>
</div></div><div><div><div>template&lt;class T&gt; array&lt;T, 0&gt; make_a=
rray();</div></div></div><div><div>template&lt;class T, class... Ts&gt; arr=
ay&lt;T, 1 + sizeof...(Ts)&gt; make_array(T, Ts...);</div></div></div></blo=
ckquote>
<div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2014/n3824.htm">N3824</a>=C2=A0has already proposed pretty much exac=
tly this. It doesn&#39;t have the iterator overload, but that overload is p=
roblematic in a lot of ways, and seems superfluous to the goals of array in=
teroperability and bound deduction, so I don&#39;t see a need to add it.</d=
iv>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><=
/div><div>This gives improved interoperability and unknown bound deduction,=
 without having to bless a library type into core.</div>
<div><br></div><div>Regards, Ed</div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a1134a21a66780b04f7cbccee--

.

------=_Part_1388_10957085.1398357154181
Content-Type: text/plain; charset=UTF-8



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<javascript:>
> > 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 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3824.htm> 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.

--

---
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_1388_10957085.1398357154181
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, 24 April 2014 16:49:46 UTC+1, Geoffre=
y Romer  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><br><div class=3D"gmail_quote">On Thu, Apr 24, 2014 at 1:04 AM, Edwa=
rd Catmur <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"lnPenp7iCTcJ" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">e...@c=
atmur.co.uk</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Couldn't we get most of the=
 way just with some improvements to the library? For example:<div><br></div=
>
<div>First, require that std::array representation actually contain an arra=
y T[N] (except for N=3D0), and make this accessible, by changing the data m=
ember function to T (&amp;data())[N] (again unless N=3D0):</div><div><br></=
div>
<div><div>T (&amp;data())[N];</div></div><div><div>const T (&amp;data() con=
st)[N];</div></div></div></blockquote></div></div></div></blockquote><div>&=
nbsp;</div><div>Wondering - do you know whether this has previously been pr=
oposed, or indeed why C++11 std::array does not have array typed member acc=
ess?</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>Next, provide a std::make_array function, in four v=
ariants:</div><div><br></div><div><div>template&lt;class T, size_t N&gt; ar=
ray&lt;T, N&gt; make_array(T (&amp;)[N]);</div></div><div><div><div>templat=
e&lt;class T, size_t N, class InputIt&gt; array&lt;T, N&gt; make_array(Inpu=
tIt);</div>
</div></div><div><div><div>template&lt;class T&gt; array&lt;T, 0&gt; make_a=
rray();</div></div></div><div><div>template&lt;class T, class... Ts&gt; arr=
ay&lt;T, 1 + sizeof...(Ts)&gt; make_array(T, Ts...);</div></div></div></blo=
ckquote>
<div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2014/n3824.htm" target=3D"_blank" onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%=
2Fdocs%2Fpapers%2F2014%2Fn3824.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNEhx1e=
9tIZMmvWN5XDo2AJKkX3rJw';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs=
%2Fpapers%2F2014%2Fn3824.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNEhx1e9tIZMm=
vWN5XDo2AJKkX3rJw';return true;">N3824</a>&nbsp;has already proposed pretty=
 much exactly this. It doesn't have the iterator overload, but that overloa=
d is problematic in a lot of ways, and seems superfluous to the goals of ar=
ray interoperability and bound deduction, so I don't see a need to add it.<=
/div></div></div></div></blockquote><div><br></div><div>Adding an iterator =
overload enables construction from vector and from array slices, where othe=
rwise the temptation would be to use a cast to array type. I agree it's not=
 strictly necessary.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_1388_10957085.1398357154181--

.

--001a11c3cdee2953ea04f7cd7a4c
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 24, 2014 at 9:32 AM, Edward Catmur <ed@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.

--

---
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/.

--001a11c3cdee2953ea04f7cd7a4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Apr 24, 2014 at 9:32 AM, Edward Catmur <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, 24 Apr=
il 2014 16:49:46 UTC+1, Geoffrey Romer  wrote:<div class=3D""><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br><div class=3D"gmail_quote">On Thu, Apr 24, 2014 a=
t 1:04 AM, Edward Catmur <span dir=3D"ltr">&lt;<a>e...@catmur.co.uk</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Couldn&#39;t we get most of=
 the way just with some improvements to the library? For example:<div><br><=
/div>

<div>First, require that std::array representation actually contain an arra=
y T[N] (except for N=3D0), and make this accessible, by changing the data m=
ember function to T (&amp;data())[N] (again unless N=3D0):</div><div><br></=
div>

<div><div>T (&amp;data())[N];</div></div><div><div>const T (&amp;data() con=
st)[N];</div></div></div></blockquote></div></div></div></blockquote><div>=
=C2=A0</div></div><div>Wondering - do you know whether this has previously =
been proposed, or indeed why C++11 std::array does not have array typed mem=
ber access?</div>
</div></blockquote><div><br></div><div>I don&#39;t know, but my guess is th=
at it&#39;s because data() would have to be SFINAEd out in the N=3D0 case, =
which complicates the API, and could greatly complicate user code that mani=
pulates arrays generically. Which, now that I think about it, pretty much s=
inks 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 mem=
ber function that returns an array reference.</div>
<div><br></div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11c3cdee2953ea04f7cd7a4c--

.

------=_Part_19_11908345.1398521816398
Content-Type: text/plain; charset=UTF-8

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.

--

---
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_19_11908345.1398521816398
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 21, 2014 5:50:34 AM UTC+2, David Krauss w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div>I think <font face=3D"Courier">std::array_view</font> is su=
pposed to be the general solution, no?</div></div></blockquote><div><br></d=
iv><div>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 se=
ems like the perfect solution.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_19_11908345.1398521816398--

.