Topic: Uniform initialization
Author: jsphadetula@gmail.com
Date: Sat, 18 Apr 2015 08:54:39 -0700 (PDT)
Raw View
------=_Part_1748_416216817.1429372479988
Content-Type: text/plain; charset=UTF-8
Can the C++ language disambiguate between initializer list and constructor call using @:
MyType myTypeVar = @{...}; //constructor call
vector<T> vec ={...}; //use current semantics
--
---
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_1748_416216817.1429372479988--
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 18 Apr 2015 09:25:35 -0700 (PDT)
Raw View
------=_Part_11_688195887.1429374335785
Content-Type: multipart/alternative;
boundary="----=_Part_12_161350067.1429374335785"
------=_Part_12_161350067.1429374335785
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I would rather suggest removing 'std::initializer_list' as it can be fully=
=20
replaced by using arrays. It only creates confusion and pollutes the new=20
initialization syntax.
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201=
5 =D0=B3., 18:54:40 UTC+3, Olanrewaju Adetula =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:
>
> Can the C++ language disambiguate between initializer list and constructo=
r=20
> call using @:=20
>
> MyType myTypeVar =3D @{...}; //constructor call=20
> vector<T> vec =3D{...}; //use current semantics
--=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_12_161350067.1429374335785
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would rather suggest removing '<span style=3D"color: rgb=
(84, 84, 84); font-family: arial, sans-serif; font-size: small; line-height=
: 18.2000007629395px;">std::</span><wbr style=3D"color: rgb(84, 84, 84); fo=
nt-family: arial, sans-serif; font-size: small; line-height: 18.20000076293=
95px;"><span style=3D"font-weight: bold; color: rgb(106, 106, 106); font-fa=
mily: arial, sans-serif; font-size: small; line-height: 18.2000007629395px;=
">initializer_list</span>' as it can be fully replaced by using arrays. It =
only creates confusion and pollutes the new initialization syntax.<br><br>=
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201=
5 =D0=B3., 18:54:40 UTC+3, Olanrewaju Adetula =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Can the C++ language=
disambiguate between initializer list and constructor call using @:
<br>
<br>MyType myTypeVar =3D @{...}; //constructor call
<br>vector<T> vec =3D{...}; //use current semantics</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" 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_12_161350067.1429374335785--
------=_Part_11_688195887.1429374335785--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 18 Apr 2015 13:53:38 -0700
Raw View
On Saturday 18 April 2015 09:25:35 Alexander Marinov wrote:
> I would rather suggest removing 'std::initializer_list' as it can be fully
> replaced by using arrays. It only creates confusion and pollutes the new
> initialization syntax.
Please explain how initializer_list can be replaced by arrays.
--
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
--
---
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/.
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 18 Apr 2015 14:02:40 -0700 (PDT)
Raw View
------=_Part_403_684074891.1429390960603
Content-Type: multipart/alternative;
boundary="----=_Part_404_1766730646.1429390960603"
------=_Part_404_1766730646.1429390960603
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Well - very simple. You just need to replace *std::initializer_list *with=
=20
*std::array*.
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201=
5 =D0=B3., 23:53:42 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>
> On Saturday 18 April 2015 09:25:35 Alexander Marinov wrote:=20
> > I would rather suggest removing 'std::initializer_list' as it can be=20
> fully=20
> > replaced by using arrays. It only creates confusion and pollutes the ne=
w=20
> > initialization syntax.=20
>
> Please explain how initializer_list can be replaced by arrays.=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>
>
--=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_404_1766730646.1429390960603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well - very simple. You just need to replace <b>std::=
initializer_list </b>with <b>std::array</b>.<br><br><br>=D1=81=D1=8A=D0=B1=
=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2015 =D0=B3., 23:53:4=
2 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">On Saturday 18 April 2015 09:25:35 Alexande=
r Marinov wrote:
<br>> I would rather suggest removing 'std::initializer_list' as it can =
be fully
<br>> replaced by using arrays. It only creates confusion and pollutes t=
he new
<br>> initialization syntax.
<br>
<br>Please explain how initializer_list can be replaced by arrays.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></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" 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_404_1766730646.1429390960603--
------=_Part_403_684074891.1429390960603--
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 18 Apr 2015 14:02:46 -0700 (PDT)
Raw View
------=_Part_1973_303365989.1429390966781
Content-Type: multipart/alternative;
boundary="----=_Part_1974_545999145.1429390966781"
------=_Part_1974_545999145.1429390966781
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Well - very simple. You just need to replace *std::initializer_list *with=
=20
*std::array*.
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201=
5 =D0=B3., 23:53:42 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>
> On Saturday 18 April 2015 09:25:35 Alexander Marinov wrote:=20
> > I would rather suggest removing 'std::initializer_list' as it can be=20
> fully=20
> > replaced by using arrays. It only creates confusion and pollutes the ne=
w=20
> > initialization syntax.=20
>
> Please explain how initializer_list can be replaced by arrays.=20
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>
>
--=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_1974_545999145.1429390966781
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well - very simple. You just need to replace <b>std::=
initializer_list </b>with <b>std::array</b>.<br><br><br>=D1=81=D1=8A=D0=B1=
=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2015 =D0=B3., 23:53:4=
2 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">On Saturday 18 April 2015 09:25:35 Alexande=
r Marinov wrote:
<br>> I would rather suggest removing 'std::initializer_list' as it can =
be fully
<br>> replaced by using arrays. It only creates confusion and pollutes t=
he new
<br>> initialization syntax.
<br>
<br>Please explain how initializer_list can be replaced by arrays.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></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" 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_1974_545999145.1429390966781--
------=_Part_1973_303365989.1429390966781--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 18 Apr 2015 14:05:18 -0700
Raw View
On Saturday 18 April 2015 14:02:40 Alexander Marinov wrote:
> Well - very simple. You just need to replace *std::initializer_list *with
> *std::array*.
Will that work for constexpr initialisation, without allocating memory?
--
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
--
---
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/.
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 18 Apr 2015 14:09:04 -0700 (PDT)
Raw View
------=_Part_1940_1120320569.1429391344989
Content-Type: multipart/alternative;
boundary="----=_Part_1941_91186287.1429391344989"
------=_Part_1941_91186287.1429391344989
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It should work all the cases that *std::initializer_list* do.
=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201=
5 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:
>
> On Saturday 18 April 2015 14:02:40 Alexander Marinov wrote:=20
> > Well - very simple. You just need to replace *std::initializer_list=20
> *with=20
> > *std::array*.=20
>
> Will that work for constexpr initialisation, without allocating memory?=
=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>
>
--=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_1941_91186287.1429391344989
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It should work all the cases that *std::initializer_l=
ist* do.<br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=
=D0=B8=D0=BB 2015 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Satur=
day 18 April 2015 14:02:40 Alexander Marinov wrote:
<br>> Well - very simple. You just need to replace *std::initializer_lis=
t *with
<br>> *std::array*.
<br>
<br>Will that work for constexpr initialisation, without allocating memory?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></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" 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_1941_91186287.1429391344989--
------=_Part_1940_1120320569.1429391344989--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Sat, 18 Apr 2015 16:17:41 -0500
Raw View
--001a11c33d329813970514063c29
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 18 April 2015 at 16:09, Alexander Marinov <sasho648@mail.bg> wrote:
> It should work all the cases that *std::initializer_list* do.
>
1. Why??
2. What are the motivating use cases for initializer_list being bad and
array being good?
3. array has different copy semantics.
4. Using array would require all the constructors that use it to be in
the header, as you'd have to templatize on the size of the array.
5. Huge breaking change.
>
>
> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2=
015 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>
>> On Saturday 18 April 2015 14:02:40 Alexander Marinov wrote:
>> > Well - very simple. You just need to replace *std::initializer_list
>> *with
>> > *std::array*.
>>
>> Will that work for constexpr initialisation, without allocating memory?
>>
>> --
>> 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
>>
>> --
>
> ---
> 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/.
>
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=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/.
--001a11c33d329813970514063c29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 18 April 2015 at 16:09, Alexander Marinov <span dir=3D"=
ltr"><<a href=3D"mailto:sasho648@mail.bg" target=3D"_blank">sasho648@mai=
l.bg</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It should work all=
the cases that=C2=A0*std::initializer_list* do.</div></blockquote><div><br=
></div><div><ol><li>Why??</li><li>What are the motivating use cases for ini=
tializer_list being bad and array being good?</li><li>array has different c=
opy semantics.</li><li>Using array would require all the constructors that =
use it to be in the header, as you'd have to templatize on the size of =
the array.</li><li>Huge breaking change.</li></ol></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"h5"><br><b=
r>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2=
015 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">On Saturday 18 April 2015 14=
:02:40 Alexander Marinov wrote:
<br>> Well - very simple. You just need to replace *std::initializer_lis=
t *with
<br>> *std::array*.
<br>
<br>Will that work for constexpr initialisation, without allocating memory?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></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" 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><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">=C2=A0Nevin ":-)" Liber=C2=A0 <=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>>=C2=A0 (847) 691-1404</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" 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 />
--001a11c33d329813970514063c29--
.
Author: Alexander Marinov <sasho648@mail.bg>
Date: Sat, 18 Apr 2015 14:42:38 -0700 (PDT)
Raw View
------=_Part_2074_1384864485.1429393358058
Content-Type: multipart/alternative;
boundary="----=_Part_2075_989633209.1429393358058"
------=_Part_2075_989633209.1429393358058
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yeah after ISO released them. Maybe you're right. Then perhaps it will be=
=20
better to modify the 'std::vector' class instead. I don't think adding new=
=20
syntax for such a small thing will be accepted.
=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 201=
5 =D0=B3., 0:18:25 UTC+3, Nevin ":-)" Liber =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>
> On 18 April 2015 at 16:09, Alexander Marinov <sash...@mail.bg=20
> <javascript:>> wrote:
>
>> It should work all the cases that *std::initializer_list* do.
>>
>
>
> 1. Why??
> 2. What are the motivating use cases for initializer_list being bad=20
> and array being good?
> 3. array has different copy semantics.
> 4. Using array would require all the constructors that use it to be in=
=20
> the header, as you'd have to templatize on the size of the array.
> 5. Huge breaking change.
>
> =20
>
>>
>>
>> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB =
2015 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>>
>>> On Saturday 18 April 2015 14:02:40 Alexander Marinov wrote:=20
>>> > Well - very simple. You just need to replace *std::initializer_list=
=20
>>> *with=20
>>> > *std::array*.=20
>>>
>>> Will that work for constexpr initialisation, without allocating memory?=
=20
>>>
>>> --=20
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>>> Software Architect - Intel Open Source Technology Center=20
>>> PGP/GPG: 0x6EF45358; fingerprint:=20
>>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>>>
>>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
>
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)=
=20
> 691-1404
> =20
--=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_2075_989633209.1429393358058
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yeah after ISO released them. Maybe you're right. Then per=
haps it will be better to modify the 'std::vector' class instead. I don't t=
hink adding new syntax for such a small thing will be accepted.<br><br>=D0=
=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2015 =
=D0=B3., 0:18:25 UTC+3, Nevin ":-)" Liber =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:<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 18 Apr=
il 2015 at 16:09, Alexander Marinov <span dir=3D"ltr"><<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ix5UFP3814QJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">sash...@mail.bg</a>></span> wrote:<=
br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">It should work all the cases that *std::initializer_list* do.=
</div></blockquote><div><br></div><div><ol><li>Why??</li><li>What are the m=
otivating use cases for initializer_list being bad and array being good?</l=
i><li>array has different copy semantics.</li><li>Using array would require=
all the constructors that use it to be in the header, as you'd have to tem=
platize on the size of the array.</li><li>Huge breaking change.</li></ol></=
div><div> </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"><div><=
div><br><br>=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=
=B8=D0=BB 2015 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday 18 A=
pril 2015 14:02:40 Alexander Marinov wrote:
<br>> Well - very simple. You just need to replace *std::initializer_lis=
t *with
<br>> *std::array*.
<br>
<br>Will that work for constexpr initialisation, without allocating memory?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEsw=
DUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thia=
go (AT) <a href=3D"http://kde.org" rel=3D"nofollow" target=3D"_blank" onmou=
sedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.o=
rg\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return =
true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
Ix5UFP3814QJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"Ix5UFP3814QJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div> Nevin ":-)" Liber <mailto:<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"Ix5UFP3814QJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">ne...@eviloverlord.com</a><wbr>> (847) 69=
1-1404</div>
</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" 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_2075_989633209.1429393358058--
------=_Part_2074_1384864485.1429393358058--
.
Author: Olanrewaju Adetula <jsphadetula@gmail.com>
Date: Sat, 18 Apr 2015 22:51:00 +0100
Raw View
--089e014946004f8274051406b18d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Changing the vector class will not necessarily solve inherent ambiguity
because initializer list has preference over constructor calls.
Initializer can always be called by mistake if the intended parameters are
the same type, although such cases are small I believe but having such a
syntax will make the programmer's intention clear
On Apr 18, 2015 10:42 PM, "Alexander Marinov" <sasho648@mail.bg> wrote:
> Yeah after ISO released them. Maybe you're right. Then perhaps it will be
> better to modify the 'std::vector' class instead. I don't think adding ne=
w
> syntax for such a small thing will be accepted.
>
> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2=
015 =D0=B3., 0:18:25 UTC+3, Nevin ":-)" Liber =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:
>>
>> On 18 April 2015 at 16:09, Alexander Marinov <sash...@mail.bg> wrote:
>>
>>> It should work all the cases that *std::initializer_list* do.
>>>
>>
>>
>> 1. Why??
>> 2. What are the motivating use cases for initializer_list being bad
>> and array being good?
>> 3. array has different copy semantics.
>> 4. Using array would require all the constructors that use it to be
>> in the header, as you'd have to templatize on the size of the array.
>> 5. Huge breaking change.
>>
>>
>>
>>>
>>>
>>> =D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB=
2015 =D0=B3., 0:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:
>>>>
>>>> On Saturday 18 April 2015 14:02:40 Alexander Marinov wrote:
>>>> > Well - very simple. You just need to replace *std::initializer_list
>>>> *with
>>>> > *std::array*.
>>>>
>>>> Will that work for constexpr initialisation, without allocating memory=
?
>>>>
>>>> --
>>>> 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
>>>>
>>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
>>
>> --
>> Nevin ":-)" Liber <mailto:ne...@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/.
>
--=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/.
--089e014946004f8274051406b18d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Changing the vector class will not necessarily solve inheren=
t ambiguity because initializer list has preference over constructor calls.=
<br>
Initializer can always be called by mistake if the intended parameters are =
the same type, although such cases are small I believe but having such a sy=
ntax will make the programmer's intention clear </p>
<div class=3D"gmail_quote">On Apr 18, 2015 10:42 PM, "Alexander Marino=
v" <<a href=3D"mailto:sasho648@mail.bg">sasho648@mail.bg</a>> wr=
ote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Yeah after ISO released them. Maybe you're right. Then perhaps it wil=
l be better to modify the 'std::vector' class instead. I don't =
think adding new syntax for such a small thing will be accepted.<br><br>=D0=
=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2015 =
=D0=B3., 0:18:25 UTC+3, Nevin ":-)" Liber =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:<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=
18 April 2015 at 16:09, Alexander Marinov <span dir=3D"ltr"><<a rel=3D"=
nofollow">sash...@mail.bg</a>></span> wrote:<br><div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It should work all =
the cases that=C2=A0*std::initializer_list* do.</div></blockquote><div><br>=
</div><div><ol><li>Why??</li><li>What are the motivating use cases for init=
ializer_list being bad and array being good?</li><li>array has different co=
py semantics.</li><li>Using array would require all the constructors that u=
se it to be in the header, as you'd have to templatize on the size of t=
he array.</li><li>Huge breaking change.</li></ol></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><br><br>=D0=BD=D0=B5=
=D0=B4=D0=B5=D0=BB=D1=8F, 19 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2015 =D0=B3., 0=
:05:21 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex">On Saturday 18 April 2015 14:02:40 Alexande=
r Marinov wrote:
<br>> Well - very simple. You just need to replace *std::initializer_lis=
t *with
<br>> *std::array*.
<br>
<br>Will that work for constexpr initialisation, without allocating memory?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a rel=3D"nofollow"=
>ne...@eviloverlord.com</a>>=C2=A0 (847) 691-1404</div>
</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" 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>
</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" 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 />
--089e014946004f8274051406b18d--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sat, 18 Apr 2015 16:00:24 -0700
Raw View
--047d7b3a7f7e81a239051407a91b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Apr 18, 2015 at 2:02 PM, Alexander Marinov <sasho648@mail.bg> wrote=
:
> Well - very simple. You just need to replace *std::initializer_list *with
> *std::array*.
>
The design of std::initializer_list deliberately avoids including the size
of the list in the type, so you don't need to write a constructor template
to handle a list of arbitrary length. std::array doesn't satisfy this use
case.
> =D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2=
015 =D0=B3., 23:53:42 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>
>> On Saturday 18 April 2015 09:25:35 Alexander Marinov wrote:
>> > I would rather suggest removing 'std::initializer_list' as it can be
>> fully
>> > replaced by using arrays. It only creates confusion and pollutes the
>> new
>> > initialization syntax.
>>
>> Please explain how initializer_list can be replaced by arrays.
>> --
>> 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
>>
>> --
>
> ---
> 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/.
>
--=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/.
--047d7b3a7f7e81a239051407a91b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Apr 18, 2015 at 2:02 PM, Alexander Marinov <span dir=3D"ltr"><<a hre=
f=3D"mailto:sasho648@mail.bg" target=3D"_blank">sasho648@mail.bg</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Well - very =
simple. You just need to replace=C2=A0<b>std::initializer_list </b>with <b>=
std::array</b>.</div></blockquote><div><br></div><div>The design of std::in=
itializer_list deliberately avoids including the size of the list in the ty=
pe, so you don't need to write a constructor template to handle a list =
of arbitrary length. std::array doesn't satisfy this use case.</div><di=
v>=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"><div><div cla=
ss=3D"h5">=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=
=D0=BB 2015 =D0=B3., 23:53:42 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday 18 Apri=
l 2015 09:25:35 Alexander Marinov wrote:
<br>> I would rather suggest removing 'std::initializer_list' as=
it can be fully
<br>> replaced by using arrays. It only creates confusion and pollutes t=
he new
<br>> initialization syntax.
<br>
<br>Please explain how initializer_list can be replaced by arrays.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></div></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" 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" 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 />
--047d7b3a7f7e81a239051407a91b--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 20 Apr 2015 09:36:38 +0100
Raw View
--001a1133b1c417db63051423d47b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Since we are throwing wild, hard or impossible to do ideas around
'std::initializer_list', what about making it a bit more cumbersome to use:
std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]
std::vector<int> b{1, 2}; // vector with contents [ 2 ]
Why? Just to bother people... not really. This would make the use of
initializer lists slightly more cumbersome (not much, once you are typing
the first {, pressing twice is not a huge deal and the same goes for }) but
allow clearer distinction of this versus non-initializer lists arguments,
which would be helpful in the context of some papers like N4029, by
allowing the selection of a non-initializer list constructor when an
initializer-list is present:
struct A {
A(double);
A(std::initializer_list<int>);
A(int);
};
A f() {
return { 1. }; // error: narrowing conversion from double to int ->
could be legal
}
A g() {
return {{ 1 }}; // initializer_list constructor
}
A h() {
return { 1 }; // int constructor
}
But as I mentioned before, probably too much of a breaking change, as it
would change the semantics of existing programs:
std::vector<int> f() {
return { 5 }; // returns [ 10 ], would return [ 0, 0, 0, 0, 0 ]
}
.... nevertheless I wish this had been the initial design.
David
On Sun, Apr 19, 2015 at 12:00 AM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On Sat, Apr 18, 2015 at 2:02 PM, Alexander Marinov <sasho648@mail.bg>
> wrote:
>
>> Well - very simple. You just need to replace *std::initializer_list *wit=
h
>> *std::array*.
>>
>
> The design of std::initializer_list deliberately avoids including the siz=
e
> of the list in the type, so you don't need to write a constructor templat=
e
> to handle a list of arbitrary length. std::array doesn't satisfy this use
> case.
>
>
>> =D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB =
2015 =D0=B3., 23:53:42 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:
>>>
>>> On Saturday 18 April 2015 09:25:35 Alexander Marinov wrote:
>>> > I would rather suggest removing 'std::initializer_list' as it can be
>>> fully
>>> > replaced by using arrays. It only creates confusion and pollutes the
>>> new
>>> > initialization syntax.
>>>
>>> Please explain how initializer_list can be replaced by arrays.
>>> --
>>> 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
>>>
>>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>
--=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/.
--001a1133b1c417db63051423d47b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Since we are throwing wild, hard or impossible to do ideas=
around 'std::initializer_list', what about making it a bit more cu=
mbersome to use:<br><br>std::vector<int> a{{1, 2}}; // vector with co=
ntents [ 1, 2 ]<br>std::vector<int> b{1, 2}; =C2=A0 // vector with co=
ntents [ 2 ]<br><br>Why? Just to bother people... not really. This would ma=
ke the use of initializer lists slightly more cumbersome (not much, once yo=
u are typing the first {, pressing twice is not a huge deal and the same go=
es for }) but allow clearer distinction of this versus non-initializer list=
s arguments, which would be helpful in the context of some papers like=C2=
=A0N4029, by allowing the selection of a non-initializer list constructor w=
hen an initializer-list is present:<br><br>struct A {<br>=C2=A0 =C2=A0A(dou=
ble);<br>=C2=A0 =C2=A0A(std::initializer_list<int>);<br>=C2=A0 =C2=A0=
A(int);<br>};<br>A f() {<div>=C2=A0 =C2=A0return { 1. }; =C2=A0 // error: n=
arrowing conversion from double to int -> could be legal<br>}<br>A g() {=
<br>=C2=A0 =C2=A0return {{ 1 }}; // initializer_list constructor<br>}<br>A =
h() {<br>=C2=A0 =C2=A0 return { 1 }; // int constructor<br>}<br><br>But as =
I mentioned before, probably too much of a breaking change, as it would cha=
nge the semantics of existing programs:<br><br>std::vector<int> f() {=
<br>=C2=A0 =C2=A0 return { 5 }; =C2=A0 =C2=A0 =C2=A0 =C2=A0 // returns [ 10=
], would return [ 0, 0, 0, 0, 0 ]<br>}<br><br>... nevertheless I wish this=
had been the initial design.<br><br>=C2=A0 =C2=A0 David</div></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Apr 19, 2015 at =
12:00 AM, Richard Smith <span dir=3D"ltr"><<a href=3D"mailto:richard@met=
afoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><span class=3D"">On Sat, Apr 18, 2015 at 2:02 =
PM, Alexander Marinov <span dir=3D"ltr"><<a href=3D"mailto:sasho648@mail=
..bg" target=3D"_blank">sasho648@mail.bg</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">Well - very simple. You just need to =
replace=C2=A0<b>std::initializer_list </b>with <b>std::array</b>.</div></bl=
ockquote><div><br></div></span><div>The design of std::initializer_list del=
iberately avoids including the size of the list in the type, so you don'=
;t need to write a constructor template to handle a list of arbitrary lengt=
h. std::array doesn't satisfy this use case.</div><div><div class=3D"h5=
"><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"><div><di=
v>=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=B0=D0=BF=D1=80=D0=B8=D0=BB 2=
015 =D0=B3., 23:53:42 UTC+3, Thiago Macieira =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">On Saturday 18 April 2015 09=
:25:35 Alexander Marinov wrote:
<br>> I would rather suggest removing 'std::initializer_list' as=
it can be fully
<br>> replaced by using arrays. It only creates confusion and pollutes t=
he new
<br>> initialization syntax.
<br>
<br>Please explain how initializer_list can be replaced by arrays.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"n=
ofollow" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http:=
//kde.org" rel=3D"nofollow" target=3D"_blank">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
<br>=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4=
5358
<br>
<br></blockquote></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" 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></div></div><br></div></div><div class=3D"HO=
EnZb"><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" 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>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1133b1c417db63051423d47b--
.
Author: Roman Perepelitsa <roman.perepelitsa@gmail.com>
Date: Mon, 20 Apr 2015 10:48:48 +0200
Raw View
--089e0158c16ed34e9d05142400f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 20, 2015 at 10:36 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.o=
rg>
wrote:
> Since we are throwing wild, hard or impossible to do ideas around
> 'std::initializer_list', what about making it a bit more cumbersome to us=
e:
>
> std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]
> std::vector<int> b{1, 2}; // vector with contents [ 2 ]
>
That's how it should have been done IMO. All problems caused by initializer
lists stem from their magic ability of inserting an extra pair of curly
braces. As you correctly pointed out, this aspect is unlikely to change.
Roman Perepelitsa.
--=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/.
--089e0158c16ed34e9d05142400f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 20, 2015 at 10:36 AM, David Rodr=C3=ADguez Ibeas <span dir=3D"ltr">=
<<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Sinc=
e we are throwing wild, hard or impossible to do ideas around 'std::ini=
tializer_list', what about making it a bit more cumbersome to use:<br><=
br>std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]<br>st=
d::vector<int> b{1, 2}; =C2=A0 // vector with contents [ 2 ]<br></div=
></blockquote><div><br></div><div>That's how it should have been done I=
MO. All problems caused by initializer lists stem from their magic ability =
of inserting an extra pair of curly braces. As you correctly pointed out, t=
his aspect is unlikely to change.</div><div><br></div><div>Roman Perepelits=
a.</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" 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 />
--089e0158c16ed34e9d05142400f1--
.
Author: Olanrewaju Adetula <jsphadetula@gmail.com>
Date: Mon, 20 Apr 2015 12:57:38 +0100
Raw View
--001a11c3564efe7a36051426a226
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Since initializer list currently takes precedence, then adapting {{}} for
strict initialization would be better.
It will eventually even make more sense in my opinion because {{}} can lead
to subtle confusion when working with maps as that can easily lead to three
{ for the first key-value pair
On Apr 20, 2015 9:49 AM, "Roman Perepelitsa" <roman.perepelitsa@gmail.com>
wrote:
> On Mon, Apr 20, 2015 at 10:36 AM, David Rodr=C3=ADguez Ibeas <dibeas@ieee=
..org>
> wrote:
>
>> Since we are throwing wild, hard or impossible to do ideas around
>> 'std::initializer_list', what about making it a bit more cumbersome to u=
se:
>>
>> std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]
>> std::vector<int> b{1, 2}; // vector with contents [ 2 ]
>>
>
> That's how it should have been done IMO. All problems caused by
> initializer lists stem from their magic ability of inserting an extra pai=
r
> of curly braces. As you correctly pointed out, this aspect is unlikely to
> change.
>
> Roman Perepelitsa.
>
> --
>
> ---
> 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/.
>
--=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/.
--001a11c3564efe7a36051426a226
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Since initializer list currently takes precedence, then adap=
ting {{}} for strict initialization would be better. <br>
It will eventually even make more sense in my opinion because {{}} can lead=
to subtle confusion when working with maps as that can easily lead to thre=
e { for the first key-value pair</p>
<div class=3D"gmail_quote">On Apr 20, 2015 9:49 AM, "Roman Perepelitsa=
" <<a href=3D"mailto:roman.perepelitsa@gmail.com">roman.perepelitsa=
@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On Mon, Apr 20, 2015 at 10:36 AM, David Rodr=C3=ADguez Ibeas <span dir=3D=
"ltr"><<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.=
org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">Since we are throwing wild, hard or impossible to do ideas around 'st=
d::initializer_list', what about making it a bit more cumbersome to use=
:<br><br>std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]=
<br>std::vector<int> b{1, 2}; =C2=A0 // vector with contents [ 2 ]<br=
></div></blockquote><div><br></div><div>That's how it should have been =
done IMO. All problems caused by initializer lists stem from their magic ab=
ility of inserting an extra pair of curly braces. As you correctly pointed =
out, this aspect is unlikely to change.</div><div><br></div><div>Roman Pere=
pelitsa.</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" 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>
</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" 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 />
--001a11c3564efe7a36051426a226--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 20 Apr 2015 21:59:13 +0800
Raw View
--Apple-Mail=_02F8172C-B683-4601-A2EF-637BED1896C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9304=E2=80=9320, at 4:36 PM, David Rodr=C3=ADguez Ibeas <di=
beas@ieee.org> wrote:
>=20
> Since we are throwing wild, hard or impossible to do ideas around 'std::i=
nitializer_list', what about making it a bit more cumbersome to use:
>=20
> std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]
> std::vector<int> b{1, 2}; // vector with contents [ 2 ]
>=20
> Why? Just to bother people... not really. This would make the use of init=
ializer lists slightly more cumbersome (not much, once you are typing the f=
irst {, pressing twice is not a huge deal and the same goes for }) but allo=
w clearer distinction of this versus non-initializer lists arguments,
You=E2=80=99re almost proposing deprecation of direct-list-initialization, =
if the intent is to make braces and parens behave exactly the same. The onl=
y obvious remaining difference would be that it works with aggregates, but =
it=E2=80=99s been suggested (by Richard, quite reasonably IMHO) that parens=
work for them too, at least at the top level. Is there anything else?
> which would be helpful in the context of some papers like N4029, by allow=
ing the selection of a non-initializer list constructor when an initializer=
-list is present:
>=20
> A g() {
> return {{ 1 }}; // initializer_list constructor
> }
> A h() {
> return { 1 }; // int constructor
> }
Braces tend to represent, or at least look like, aggregation. When an initi=
alizer_list constructor is present, it usurps the braces because the class =
is usually representing an aggregation of objects. It=E2=80=99s a bit of ab=
use to return braces as a universal shortcut for other sorts of initializat=
ion parameters. It=E2=80=99s unfortunate that good style must be violated t=
o return a non-movable object, since braced-init-list conversion is the onl=
y way, but in other cases the keystrokes of the type-name are worth it.
(By the way, all your examples currently work with the removal of the outer=
most braces. The int and double constructors perform implicit conversions.)
--=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=_02F8172C-B683-4601-A2EF-637BED1896C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9304=
=E2=80=9320, at 4:36 PM, David Rodr=C3=ADguez Ibeas <<a href=3D"mailto:d=
ibeas@ieee.org" class=3D"">dibeas@ieee.org</a>> wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Sin=
ce we are throwing wild, hard or impossible to do ideas around 'std::initia=
lizer_list', what about making it a bit more cumbersome to use:<br class=3D=
""><br class=3D"">std::vector<int> a{{1, 2}}; // vector with contents=
[ 1, 2 ]<br class=3D"">std::vector<int> b{1, 2}; // vector wi=
th contents [ 2 ]<br class=3D""><br class=3D"">Why? Just to bother people..=
.. not really. This would make the use of initializer lists slightly more cu=
mbersome (not much, once you are typing the first {, pressing twice is not =
a huge deal and the same goes for }) but allow clearer distinction of this =
versus non-initializer lists arguments,</div></div></blockquote><div><br cl=
ass=3D""></div><div>You=E2=80=99re almost proposing deprecation of direct-l=
ist-initialization, if the intent is to make braces and parens behave exact=
ly the same. The only obvious remaining difference would be that it works w=
ith aggregates, but it=E2=80=99s been suggested (by Richard, quite reasonab=
ly IMHO) that parens work for them too, at least at the top level. Is there=
anything else?</div><br class=3D""><blockquote type=3D"cite" class=3D""><d=
iv class=3D""><div dir=3D"ltr" class=3D""> which would be helpful in the co=
ntext of some papers like N4029, by allowing the selection of a non-in=
itializer list constructor when an initializer-list is present:<br class=3D=
""><br class=3D""><div class=3D"">A g() {<br class=3D""> return=
{{ 1 }}; // initializer_list constructor<br class=3D"">}<br class=3D"">A h=
() {<br class=3D""> return { 1 }; // int constructor<br class=
=3D"">}<br class=3D""></div></div></div></blockquote><div><br class=3D""></=
div><div>Braces tend to represent, or at least look like, aggregation. When=
an <font face=3D"Courier" class=3D"">initializer_list</font> construc=
tor is present, it usurps the braces because the class is usually represent=
ing an aggregation of objects. It=E2=80=99s a bit of abuse to <font face=3D=
"Courier" class=3D"">return</font> braces as a universal shortcut for other=
sorts of initialization parameters. It=E2=80=99s unfortunate that good sty=
le must be violated to return a non-movable object, since braced-init-list =
conversion is the only way, but in other cases the keystrokes of the type-n=
ame are worth it.</div><div><br class=3D""></div><div>(By the way, all your=
examples currently work with the removal of the outermost braces. The <fon=
t face=3D"Courier" class=3D"">int</font> and <font face=3D"Courier" class=
=3D"">double</font> constructors perform implicit conversions.)</div></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" 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=_02F8172C-B683-4601-A2EF-637BED1896C6--
.
Author: inkwizytoryankes@gmail.com
Date: Mon, 20 Apr 2015 09:59:56 -0700 (PDT)
Raw View
------=_Part_12_778758880.1429549196238
Content-Type: multipart/alternative;
boundary="----=_Part_13_1835151342.1429549196238"
------=_Part_13_1835151342.1429549196238
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
How about reusing `explicit` keyword there? It will ban special behavior of=
=20
`std::initializer_list` in that type.
On Monday, April 20, 2015 at 3:59:23 PM UTC+2, David Krauss wrote:
>
>
> On 2015=E2=80=9304=E2=80=9320, at 4:36 PM, David Rodr=C3=ADguez Ibeas <di=
b...@ieee.org=20
> <javascript:>> wrote:
>
> Since we are throwing wild, hard or impossible to do ideas around=20
> 'std::initializer_list', what about making it a bit more cumbersome to us=
e:
>
> std::vector<int> a{{1, 2}}; // vector with contents [ 1, 2 ]
> std::vector<int> b{1, 2}; // vector with contents [ 2 ]
>
> Why? Just to bother people... not really. This would make the use of=20
> initializer lists slightly more cumbersome (not much, once you are typing=
=20
> the first {, pressing twice is not a huge deal and the same goes for }) b=
ut=20
> allow clearer distinction of this versus non-initializer lists arguments,
>
>
> You=E2=80=99re almost proposing deprecation of direct-list-initialization=
, if the=20
> intent is to make braces and parens behave exactly the same. The only=20
> obvious remaining difference would be that it works with aggregates, but=
=20
> it=E2=80=99s been suggested (by Richard, quite reasonably IMHO) that pare=
ns work=20
> for them too, at least at the top level. Is there anything else?
>
> which would be helpful in the context of some papers like N4029, by=20
> allowing the selection of a non-initializer list constructor when an=20
> initializer-list is present:
>
> A g() {
> return {{ 1 }}; // initializer_list constructor
> }
> A h() {
> return { 1 }; // int constructor
> }
>
>
> Braces tend to represent, or at least look like, aggregation. When an=20
> initializer_list constructor is present, it usurps the braces because the=
=20
> class is usually representing an aggregation of objects. It=E2=80=99s a b=
it of=20
> abuse to return braces as a universal shortcut for other sorts of=20
> initialization parameters. It=E2=80=99s unfortunate that good style must =
be=20
> violated to return a non-movable object, since braced-init-list conversio=
n=20
> is the only way, but in other cases the keystrokes of the type-name are=
=20
> worth it.
>
> (By the way, all your examples currently work with the removal of the=20
> outermost braces. The int and double constructors perform implicit=20
> conversions.)
>
--=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_13_1835151342.1429549196238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How about reusing `explicit` keyword there? It will ban sp=
ecial behavior of `std::initializer_list` in that type.<br><br>On Monday, A=
pril 20, 2015 at 3:59:23 PM UTC+2, David Krauss wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div><block=
quote type=3D"cite"><div>On 2015=E2=80=9304=E2=80=9320, at 4:36 PM, David R=
odr=C3=ADguez Ibeas <<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"A-ZmpJHStTEJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:';return true=
;">dib...@ieee.org</a>> wrote:</div><br><div><div dir=3D"ltr">Since we a=
re throwing wild, hard or impossible to do ideas around 'std::initializer_l=
ist', what about making it a bit more cumbersome to use:<br><br>std::vector=
<int> a{{1, 2}}; // vector with contents [ 1, 2 ]<br>std::vector<i=
nt> b{1, 2}; // vector with contents [ 2 ]<br><br>Why? Just to bo=
ther people... not really. This would make the use of initializer lists sli=
ghtly more cumbersome (not much, once you are typing the first {, pressing =
twice is not a huge deal and the same goes for }) but allow clearer distinc=
tion of this versus non-initializer lists arguments,</div></div></blockquot=
e><div><br></div><div>You=E2=80=99re almost proposing deprecation of direct=
-list-initialization, if the intent is to make braces and parens behave exa=
ctly the same. The only obvious remaining difference would be that it works=
with aggregates, but it=E2=80=99s been suggested (by Richard, quite reason=
ably IMHO) that parens work for them too, at least at the top level. Is the=
re anything else?</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr">=
which would be helpful in the context of some papers like N4029, by a=
llowing the selection of a non-initializer list constructor when an initial=
izer-list is present:<br><br><div>A g() {<br> return {{ 1 }}; /=
/ initializer_list constructor<br>}<br>A h() {<br> return { 1 =
}; // int constructor<br>}<br></div></div></div></blockquote><div><br></div=
><div>Braces tend to represent, or at least look like, aggregation. When an=
<font face=3D"Courier">initializer_list</font> constructor is present=
, it usurps the braces because the class is usually representing an aggrega=
tion of objects. It=E2=80=99s a bit of abuse to <font face=3D"Courier">retu=
rn</font> braces as a universal shortcut for other sorts of initialization =
parameters. It=E2=80=99s unfortunate that good style must be violated to re=
turn a non-movable object, since braced-init-list conversion is the only wa=
y, but in other cases the keystrokes of the type-name are worth it.</div><d=
iv><br></div><div>(By the way, all your examples currently work with the re=
moval of the outermost braces. The <font face=3D"Courier">int</font> and <f=
ont face=3D"Courier">double</font> constructors perform implicit conversion=
s.)</div></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" 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_13_1835151342.1429549196238--
------=_Part_12_778758880.1429549196238--
.
Author: Olanrewaju Adetula <jsphadetula@gmail.com>
Date: Thu, 18 Feb 2016 15:35:56 -0800 (PST)
Raw View
------=_Part_1907_725883444.1455838556213
Content-Type: multipart/alternative;
boundary="----=_Part_1908_551964890.1455838556213"
------=_Part_1908_551964890.1455838556213
Content-Type: text/plain; charset=UTF-8
how about differentiating between initializer list and constructor by
allowing for trailing comma after after the last element for an initializer
list with a compile time error if no initializer list is found
vector<int> ai = { 5, }; //initializer list
vector<int> ai = { 5 }; //constructor call
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1908_551964890.1455838556213
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>how about differentiating between initializer list an=
d constructor by allowing for trailing comma after after the last element f=
or an initializer list with a compile time error if no initializer list is =
found=C2=A0</div><div><br></div><div>vector<int>=C2=A0ai =3D { 5, }; =
=C2=A0//initializer=C2=A0list<br></div><div>vector<int>=C2=A0ai =3D {=
5 }; =C2=A0//constructor call<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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1908_551964890.1455838556213--
------=_Part_1907_725883444.1455838556213--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 19 Feb 2016 01:39:15 +0200
Raw View
On 19 February 2016 at 01:35, Olanrewaju Adetula <jsphadetula@gmail.com> wrote:
> how about differentiating between initializer list and constructor by
> allowing for trailing comma after after the last element for an initializer
> list with a compile time error if no initializer list is found
>
> vector<int> ai = { 5, }; //initializer list
> vector<int> ai = { 5 }; //constructor call
That was suggested at one point as a way to disambiguate, but it got rejected
as a disambiguation means. It might be possible to try getting such a
tweak accepted.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 19 Feb 2016 09:59:46 +0800
Raw View
--Apple-Mail=_57FA9507-BA85-4BFD-9AB5-4031C10D8A03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2016=E2=80=9302=E2=80=9319, at 7:39 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com> wrote:
>=20
> On 19 February 2016 at 01:35, Olanrewaju Adetula <jsphadetula@gmail.com> =
wrote:
>> how about differentiating between initializer list and constructor by
>> allowing for trailing comma after after the last element for an initiali=
zer
>> list with a compile time error if no initializer list is found
>>=20
>> vector<int> ai =3D { 5, }; //initializer list
>> vector<int> ai =3D { 5 }; //constructor call
>=20
>=20
> That was suggested at one point as a way to disambiguate, but it got reje=
cted
> as a disambiguation means. It might be possible to try getting such a
> tweak accepted.
This particular tweak is a massive breaking change.
Looking back over this thread, I see neither a clear motivation nor a menti=
on of the current pattern: Braces tend to represent value aggregation and p=
arens tend to represent computation by a function.
If the motivation is to get a constructor call without naming the type, how=
about the syntax auto(expression-list) to deduce (and explicitly cast to) =
a type from the given context?
The debate about implicit vs. explicit was contentious. As an implicit-to-e=
xplicit operator, this might help to find some middle ground.
struct very_long_name {
explicit very_long_name( int, int, int );
very_long_name( std::initializer_list< int > );
};
template< typename t >
void f( t && );
s factory() {
return { 1, 2, 3 }; // initializer list
return auto( 1, 2, 3 ); // constructor
return flag? very_long_name( 1, 2, 3 ) : auto{ 1, 2, 3 }; // either ini=
tializer list or constructor
f( auto{ 1, 2, 3 } ); // shortcut for initializer_list
}
The syntax auto(expr) has also been suggested to perform lvalue-to-rvalue c=
onversion, but that can be done well enough (and with a better name) by a l=
ibrary facility.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_57FA9507-BA85-4BFD-9AB5-4031C10D8A03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2016=E2=80=9302=
=E2=80=9319, at 7:39 AM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">=
On 19 February 2016 at 01:35, Olanrewaju Adetula <<a href=3D"mailto:jsph=
adetula@gmail.com" class=3D"">jsphadetula@gmail.com</a>> wrote:<br class=
=3D""><blockquote type=3D"cite" class=3D"">how about differentiating betwee=
n initializer list and constructor by<br class=3D"">allowing for trailing c=
omma after after the last element for an initializer<br class=3D"">list wit=
h a compile time error if no initializer list is found<br class=3D""><br cl=
ass=3D"">vector<int> ai =3D { 5, }; //initializer list<br class=
=3D"">vector<int> ai =3D { 5 }; //constructor call<br class=3D"=
"></blockquote><br class=3D""><br class=3D"">That was suggested at one poin=
t as a way to disambiguate, but it got rejected<br class=3D"">as a disambig=
uation means. It might be possible to try getting such a<br class=3D"">twea=
k accepted.<br class=3D""></div></div></blockquote></div><br class=3D""><di=
v class=3D"">This particular tweak is a massive breaking change.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Looking back over this thre=
ad, I see neither a clear motivation nor a mention of the current pattern: =
Braces tend to represent value aggregation and parens tend to represent com=
putation by a function.</div><div class=3D""><br class=3D""></div><div clas=
s=3D"">If the motivation is to get a constructor call without naming the ty=
pe, how about the syntax <font face=3D"Courier" class=3D"">auto(</font=
><i class=3D"">expression-list</i><font face=3D"Courier" class=3D"">)</font=
> to deduce (and explicitly cast to) a type from the given context?</div><d=
iv class=3D""><br class=3D""></div><div class=3D"">The debate about implici=
t vs. explicit was contentious. As an implicit-to-explicit operator, this m=
ight help to find some middle ground.</div><div class=3D""><br class=3D""><=
/div><div class=3D""><font face=3D"Courier" class=3D"">struct very_long_nam=
e {</font></div><div class=3D""><font face=3D"Courier" class=3D""> &n=
bsp; explicit </font><span style=3D"font-family: Courier;" class=3D"">=
very_long_name</span><font face=3D"Courier" class=3D"">( int, int, int );</=
font></div><div class=3D""><font face=3D"Courier" class=3D""> &=
nbsp;</font><span style=3D"font-family: Courier;" class=3D"">very_long_name=
</span><font face=3D"Courier" class=3D"">( std::initializer_list< int &g=
t; );</font></div><div class=3D""><font face=3D"Courier" class=3D"">};</fon=
t></div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></=
font></div><div class=3D""><font face=3D"Courier" class=3D"">template< t=
ypename t ></font></div><div class=3D""><font face=3D"Courier" class=3D"=
">void f( t && );</font></div><div class=3D""><font face=3D"Courier=
" class=3D""><br class=3D""></font></div><div class=3D""><font face=3D"Cour=
ier" class=3D"">s factory() {</font></div><div class=3D""><font face=3D"Cou=
rier" class=3D""> return { 1, 2, 3 }; // initializer list</fon=
t></div><div class=3D""><font face=3D"Courier" class=3D""> ret=
urn auto( 1, 2, 3 ); // constructor</font></div><div class=3D""><font face=
=3D"Courier" class=3D""> return flag? </font><span style=
=3D"font-family: Courier;" class=3D"">very_long_name</span><font face=3D"Co=
urier" class=3D"">( 1, 2, 3 ) : auto{ 1, 2, 3 }; // either initializer list=
or constructor</font></div><div class=3D""><font face=3D"Courier" class=3D=
""> f( auto{ 1, 2, 3 } ); // shortcut for initializer_list</fo=
nt></div><div class=3D""><font face=3D"Courier" class=3D"">}</font></div><d=
iv class=3D""><br class=3D""></div><div class=3D"">The syntax <font fa=
ce=3D"Courier" class=3D"">auto(</font><i class=3D"">expr</i><font face=3D"C=
ourier" class=3D"">)</font> has also been suggested to perform lvalue-=
to-rvalue conversion, but that can be done well enough (and with a better n=
ame) by a library facility.</div><div class=3D""><br class=3D""></div></bod=
y></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_57FA9507-BA85-4BFD-9AB5-4031C10D8A03--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 19 Feb 2016 11:10:46 +0100
Raw View
--001a11403bc66a306e052c1cb227
Content-Type: text/plain; charset=UTF-8
An alternative syntax to consider would be the explosed-initializer-list
which will prefer to expand its elements into separate constructor arguments
}a,b,c{
Am 18.04.2015 17:54 schrieb <jsphadetula@gmail.com>:
>
> Can the C++ language disambiguate between initializer list and
constructor call using @:
>
> MyType myTypeVar = @{...}; //constructor call
> vector<T> vec ={...}; //use current semantics
>
> --
>
> ---
> 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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11403bc66a306e052c1cb227
Content-Type: text/html; charset=UTF-8
<p dir="ltr">An alternative syntax to consider would be the explosed-initializer-list which will prefer to expand its elements into separate constructor arguments</p>
<p dir="ltr">}a,b,c{<br><br></p>
<p dir="ltr">Am 18.04.2015 17:54 schrieb <<a href="mailto:jsphadetula@gmail.com">jsphadetula@gmail.com</a>>:<br>
><br>
> Can the C++ language disambiguate between initializer list and constructor call using @:<br>
><br>
> MyType myTypeVar = @{...}; //constructor call<br>
> vector<T> vec ={...}; //use current semantics<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="https://groups.google.com/a/isocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--001a11403bc66a306e052c1cb227--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 19 Feb 2016 12:13:58 +0200
Raw View
On 19 February 2016 at 03:59, David Krauss <potswa@gmail.com> wrote:
>
> On 2016=E2=80=9302=E2=80=9319, at 7:39 AM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> On 19 February 2016 at 01:35, Olanrewaju Adetula <jsphadetula@gmail.com>
> wrote:
>
> how about differentiating between initializer list and constructor by
> allowing for trailing comma after after the last element for an initializ=
er
> list with a compile time error if no initializer list is found
>
> vector<int> ai =3D { 5, }; //initializer list
> vector<int> ai =3D { 5 }; //constructor call
>
>
>
> That was suggested at one point as a way to disambiguate, but it got
> rejected
> as a disambiguation means. It might be possible to try getting such a
> tweak accepted.
>
>
> This particular tweak is a massive breaking change.
Oh, I was talking about making a trailing comma mean an initializer list, n=
ot
about making the latter form always a constructor call. The suggestion
for the latter form is indeed a breaking change so massive that it is
unattainable, but changing the meaning of a trailing comma might not be
massive. Maybe.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.
Author: Olanrewaju Adetula <jsphadetula@gmail.com>
Date: Fri, 19 Feb 2016 19:12:51 +0000
Raw View
--047d7b8740068d45c1052c244598
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sorry, I meant using trailing comma for disambiguation not making the
latter always a constructor call.
That is why I used vector<int> as an example
On 11:13AM, Fri, Feb 19, 2016 Ville Voutilainen <ville.voutilainen@gmail.co=
m>
wrote:
> On 19 February 2016 at 03:59, David Krauss <potswa@gmail.com> wrote:
> >
> > On 2016=E2=80=9302=E2=80=9319, at 7:39 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com>
> > wrote:
> >
> > On 19 February 2016 at 01:35, Olanrewaju Adetula <jsphadetula@gmail.com=
>
> > wrote:
> >
> > how about differentiating between initializer list and constructor by
> > allowing for trailing comma after after the last element for an
> initializer
> > list with a compile time error if no initializer list is found
> >
> > vector<int> ai =3D { 5, }; //initializer list
> > vector<int> ai =3D { 5 }; //constructor call
> >
> >
> >
> > That was suggested at one point as a way to disambiguate, but it got
> > rejected
> > as a disambiguation means. It might be possible to try getting such a
> > tweak accepted.
> >
> >
> > This particular tweak is a massive breaking change.
>
> Oh, I was talking about making a trailing comma mean an initializer list,
> not
> about making the latter form always a constructor call. The suggestion
> for the latter form is indeed a breaking change so massive that it is
> unattainable, but changing the meaning of a trailing comma might not be
> massive. Maybe.
>
> --
>
> ---
> 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--047d7b8740068d45c1052c244598
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Sorry, I meant using trailing comma for disambiguation not m=
aking the latter always a constructor call. <br>
That is why I used vector<int> as an example </p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On 11:13AM, Fri, Feb 19, 20=
16=C2=A0Ville Voutilainen <<a href=3D"mailto:ville.voutilainen@gmail.com=
">ville.voutilainen@gmail.com</a>> wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">On 19 February 2016 at 03:59, David Krauss <<a href=3D"mailto:=
potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>> wrote:<br>
><br>
> On 2016=E2=80=9302=E2=80=9319, at 7:39 AM, Ville Voutilainen <<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>><br>
> wrote:<br>
><br>
> On 19 February 2016 at 01:35, Olanrewaju Adetula <<a href=3D"mailto=
:jsphadetula@gmail.com" target=3D"_blank">jsphadetula@gmail.com</a>><br>
> wrote:<br>
><br>
> how about differentiating between initializer list and constructor by<=
br>
> allowing for trailing comma after after the last element for an initia=
lizer<br>
> list with a compile time error if no initializer list is found<br>
><br>
> vector<int> ai =3D { 5, };=C2=A0 //initializer list<br>
> vector<int> ai =3D { 5 };=C2=A0 //constructor call<br>
><br>
><br>
><br>
> That was suggested at one point as a way to disambiguate, but it got<b=
r>
> rejected<br>
> as a disambiguation means. It might be possible to try getting such a<=
br>
> tweak accepted.<br>
><br>
><br>
> This particular tweak is a massive breaking change.<br>
<br>
Oh, I was talking about making a trailing comma mean an initializer list, n=
ot<br>
about making the latter form always a constructor call. The suggestion<br>
for the latter form is indeed a breaking change so massive that it is<br>
unattainable, but changing the meaning of a trailing comma might not be<br>
massive. Maybe.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" rel=3D"noreferrer" target=3D"_blank">https://groups.google=
..com/a/isocpp.org/group/std-proposals/</a>.<br>
</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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--047d7b8740068d45c1052c244598--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 20 Feb 2016 13:58:28 -0800 (PST)
Raw View
------=_Part_689_492136025.1456005508753
Content-Type: multipart/alternative;
boundary="----=_Part_690_8201857.1456005508753"
------=_Part_690_8201857.1456005508753
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, February 18, 2016 at 8:59:54 PM UTC-5, David Krauss wrote:
>
>
> On 2016=E2=80=9302=E2=80=9319, at 7:39 AM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> On 19 February 2016 at 01:35, Olanrewaju Adetula <jspha...@gmail.com=20
> <javascript:>> wrote:
>
> how about differentiating between initializer list and constructor by
> allowing for trailing comma after after the last element for an initializ=
er
> list with a compile time error if no initializer list is found
>
> vector<int> ai =3D { 5, }; //initializer list
> vector<int> ai =3D { 5 }; //constructor call
>
>
>
> That was suggested at one point as a way to disambiguate, but it got=20
> rejected
> as a disambiguation means. It might be possible to try getting such a
> tweak accepted.
>
>
> This particular tweak is a massive breaking change.
>
> Looking back over this thread, I see neither a clear motivation nor a=20
> mention of the current pattern: Braces tend to represent value aggregatio=
n=20
> and parens tend to represent computation by a function.
>
Is that "the current pattern"? I thought the whole point of having=20
braced-init-lists was to allow aggregation and construction to be=20
identical. It is called "Uniform Initialization", after all.
The motivation is to be able to do this:
template<typename ...Ts>
T emplace(Ts&& ...ts)
{
return T{std::forward<Ts>(ts)};
}
Where `T` can be any type. If it's an aggregate, then it will use aggregate=
=20
initialization. If it is not an aggregate, then T must have a constructor=
=20
that takes those exact arguments. None of the "if it matches an=20
initializer_list consturctor" BS.
Note that std::allocator::construct does not use braced-init-lists. Indeed,=
=20
in C++14, it was altered such that if T was an aggregate, it would use=20
braced-init-lists, and if T was not, it would not use braced-init-lists.
So there is a clear need to be able to construct a type by either aggregate=
=20
initialization or constructor call.
If the motivation is to get a constructor call without naming the type, how=
=20
> about the syntax auto(*expression-list*) to deduce (and explicitly cast=
=20
> to) a type from the given context?
>
> The debate about implicit vs. explicit was contentious. As an=20
> implicit-to-explicit operator, this might help to find some middle ground=
..
>
> struct very_long_name {
> explicit very_long_name( int, int, int );
> very_long_name( std::initializer_list< int > );
> };
>
> template< typename t >
> void f( t && );
>
> s factory() {
> return { 1, 2, 3 }; // initializer list
> return auto( 1, 2, 3 ); // constructor
> return flag? very_long_name( 1, 2, 3 ) : auto{ 1, 2, 3 }; // either=
=20
> initializer list or constructor
> f( auto{ 1, 2, 3 } ); // shortcut for initializer_list
> }
>
> The syntax auto(*expr*) has also been suggested to perform=20
> lvalue-to-rvalue conversion, but that can be done well enough (and with a=
=20
> better name) by a library facility.
>
>
Actually, this reminds me of a one-off idea I had at one point to allow=20
`return <braced-init-list>` to work. I suggested `explicit=20
<braced-init-list>`, but `auto {}` could work too.
We have two problems nowadays with braced-init-lists:
1) Unable to call explicit constructors without naming the type.
2) Initializer_list constructors taking priority when there is a conflict.
Having `auto {}` do both of these would probably be a good idea. I justify=
=20
joining these two problems because most initializer_list constructors=20
aren't marked explicit.
This should also allow you to do:
T t auto{};
That is, direct-list-initialization. Again, as a way to bypass=20
initializer_list constructors.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6c21a978-e53c-4c12-813c-b1681e225c1a%40isocpp.or=
g.
------=_Part_690_8201857.1456005508753
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, February 18, 2016 at 8:59:54 PM UTC-5, David =
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"wor=
d-wrap:break-word"><br><div><blockquote type=3D"cite"><div>On 2016=E2=80=93=
02=E2=80=9319, at 7:39 AM, Ville Voutilainen <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"VPouUnuaAAAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>> w=
rote:</div><br><div><div>On 19 February 2016 at 01:35, Olanrewaju Adetula &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"VPouU=
nuaAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">js=
pha...@gmail.com</a>> wrote:<br><blockquote type=3D"cite">how about diff=
erentiating between initializer list and constructor by<br>allowing for tra=
iling comma after after the last element for an initializer<br>list with a =
compile time error if no initializer list is found<br><br>vector<int>=
ai =3D { 5, }; =C2=A0//initializer list<br>vector<int> ai =3D { 5 };=
=C2=A0//constructor call<br></blockquote><br><br>That was suggested at one=
point as a way to disambiguate, but it got rejected<br>as a disambiguation=
means. It might be possible to try getting such a<br>tweak accepted.<br></=
div></div></blockquote></div><br><div>This particular tweak is a massive br=
eaking change.</div><div><br></div><div>Looking back over this thread, I se=
e neither a clear motivation nor a mention of the current pattern: Braces t=
end to represent value aggregation and parens tend to represent computation=
by a function.</div></div></blockquote><div><br>Is that "the current =
pattern"? I thought the whole point of having braced-init-lists was to=
allow aggregation and construction to be identical. It is called "Uni=
form Initialization", after all.<br><br>The motivation is to be able t=
o do this:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><sp=
an style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>T emplace</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Ts</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&&</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">ts</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">forward</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Ts</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ts<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br=
>Where `T` can be any type. If it's an aggregate, then it will use aggr=
egate initialization. If it is not an aggregate, then T must have a constru=
ctor that takes those exact arguments. None of the "if it matches an i=
nitializer_list consturctor" BS.<br><br>Note that std::allocator::cons=
truct does not use braced-init-lists. Indeed, in C++14, it was altered such=
that if T was an aggregate, it would use braced-init-lists, and if T was n=
ot, it would not use braced-init-lists.<br><br>So there is a clear need to =
be able to construct a type by either aggregate initialization or construct=
or call.<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 sty=
le=3D"word-wrap:break-word"><div>If the motivation is to get a constructor =
call without naming the type, how about the syntax=C2=A0<font face=3D"Couri=
er">auto(</font><i>expression-list</i><font face=3D"Courier">)</font> to de=
duce (and explicitly cast to) a type from the given context?</div><div><br>=
</div><div>The debate about implicit vs. explicit was contentious. As an im=
plicit-to-explicit operator, this might help to find some middle ground.</d=
iv><div><br></div><div><font face=3D"Courier">struct very_long_name {</font=
></div><div><font face=3D"Courier">=C2=A0 =C2=A0 explicit=C2=A0</font><span=
style=3D"font-family:Courier">very_long_name</span><font face=3D"Courier">=
( int, int, int );</font></div><div><font face=3D"Courier">=C2=A0 =C2=A0=C2=
=A0</font><span style=3D"font-family:Courier">very_long_name</span><font fa=
ce=3D"Courier">( std::initializer_list< int > );</font></div><div><fo=
nt face=3D"Courier">};</font></div><div><font face=3D"Courier"><br></font><=
/div><div><font face=3D"Courier">template< typename t ></font></div><=
div><font face=3D"Courier">void f( t && );</font></div><div><font f=
ace=3D"Courier"><br></font></div><div><font face=3D"Courier">s factory() {<=
/font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 return { 1, 2, 3 }; /=
/ initializer list</font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 re=
turn auto( 1, 2, 3 ); // constructor</font></div><div><font face=3D"Courier=
">=C2=A0 =C2=A0 return flag?=C2=A0</font><span style=3D"font-family:Courier=
">very_long_name</span><font face=3D"Courier">( 1, 2, 3 ) : auto{ 1, 2, 3 }=
; // either initializer list or constructor</font></div><div><font face=3D"=
Courier">=C2=A0 =C2=A0 f( auto{ 1, 2, 3 } ); // shortcut for initializer_li=
st</font></div><div><font face=3D"Courier">}</font></div><div><br></div><di=
v>The syntax=C2=A0<font face=3D"Courier">auto(</font><i>expr</i><font face=
=3D"Courier">)</font>=C2=A0has also been suggested to perform lvalue-to-rva=
lue conversion, but that can be done well enough (and with a better name) b=
y a library facility.</div><div><br></div></div></blockquote><div><br>Actua=
lly, this reminds me of a one-off idea I had at one point to allow `return =
<braced-init-list>` to work. I suggested `explicit <braced-init-li=
st>`, but `auto {}` could work too.<br><br>We have two problems nowadays=
with braced-init-lists:<br><br>1) Unable to call explicit constructors wit=
hout naming the type.<br><br>2) Initializer_list constructors taking priori=
ty when there is a conflict.<br><br>Having `auto {}` do both of these would=
probably be a good idea. I justify joining these two problems because most=
initializer_list constructors aren't marked explicit.<br><br>This shou=
ld also allow you to do:<br><br>T t auto{};<br><br>That is, direct-list-ini=
tialization. Again, as a way to bypass initializer_list constructors.<br></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6c21a978-e53c-4c12-813c-b1681e225c1a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6c21a978-e53c-4c12-813c-b1681e225c1a=
%40isocpp.org</a>.<br />
------=_Part_690_8201857.1456005508753--
------=_Part_689_492136025.1456005508753--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 21 Feb 2016 14:01:15 +0800
Raw View
--001a113cddf8ab6dc6052c4171d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 21, 2016 at 5:58 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, February 18, 2016 at 8:59:54 PM UTC-5, David Krauss wrote:
>>
>>
>> Looking back over this thread, I see neither a clear motivation nor a
>> mention of the current pattern: Braces tend to represent value aggregati=
on
>> and parens tend to represent computation by a function.
>>
>
> Is that "the current pattern"? I thought the whole point of having
> braced-init-lists was to allow aggregation and construction to be
> identical. It is called "Uniform Initialization", after all.
>
We have identical syntax for aggregation and construction as long as they
don't conflict. When they do conflict, we have different syntaxes to
disambiguate. It's your choice whether to maximize use of braces and
relegate parens to special cases of ambiguity, or to generalize the
pre-C++11 patterns and use braces for constructors only which perform
something like conceptual aggregation.
The term "uniform initialization" was the name the original proposal, but
it's falling out of use.
> The motivation is to be able to do this:
>
> template<typename ...Ts>
> T emplace(Ts&& ...ts)
> {
> return T{std::forward<Ts>(ts)};
> }
>
Maybe that aligns with the original motivation, but it's not what current
standard emplace members actually do. There is a proposal to use braces
like that, as a fallback when parens don't work.
If changing it only for emplace and std::allocator would be too much, then
changing it across the whole language would be worse.
> Actually, this reminds me of a one-off idea I had at one point to allow
> `return <braced-init-list>` to work. I suggested `explicit
> <braced-init-list>`, but `auto {}` could work too.
>
I remember that too. The difference is just in choice of keyword, but the
connotations are different: auto suggests to deduce something, and explicit
suggests to adjust constructor lookup.
> We have two problems nowadays with braced-init-lists:
>
> 1) Unable to call explicit constructors without naming the type.
>
> 2) Initializer_list constructors taking priority when there is a conflict=
..
>
> Having `auto {}` do both of these would probably be a good idea. I justif=
y
> joining these two problems because most initializer_list constructors
> aren't marked explicit.
>
> This should also allow you to do:
>
> T t auto{};
>
> That is, direct-list-initialization. Again, as a way to bypass
> initializer_list constructors.
>
Any brace syntax that bypasses initializer_list would be extremely
confusing. Especially one that appears to only be pulling in some harmless
deduction.
If it hurts when you use braces absolutely everywhere, then don't do that.
(The same goes for Almost Always Auto.) Such rules work well with
unsurprising, simple programs. Once one strays from value semantics, the
grammatical vocabulary needs to increase. (And besides being new, T t
auto{} would be equally non-uniform and un-generic as using parens instead
of braces!)
For std::vector, for example, there's simply no need to tell a beginner
about the constructors other than std::initializer_list. It works fine to
default-construct and then call resize or insert. If it's actually a vector
of vectors, then write a loop =E2=80=94 that's actually *more* efficient th=
an
duplicating a prototype vector. Shortcuts and terseness naturally tend to
conflict with uniformity. Maximizing one might mean sacrificing the other.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAAzFsnmKqszwTb2M4be7P9ERT0VBWOdah%2BxqRzrswtReX=
dFfxw%40mail.gmail.com.
--001a113cddf8ab6dc6052c4171d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Feb 21, 2016 at 5:58 AM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, Febru=
ary 18, 2016 at 8:59:54 PM UTC-5, David Krauss wrote:<blockquote class=3D"g=
mail_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 =
style=3D"word-wrap:break-word"><br><span class=3D""><div>Looking back over =
this thread, I see neither a clear motivation nor a mention of the current =
pattern: Braces tend to represent value aggregation and parens tend to repr=
esent computation by a function.</div></span></div></blockquote><div><br>Is=
that "the current pattern"? I thought the whole point of having =
braced-init-lists was to allow aggregation and construction to be identical=
.. It is called "Uniform Initialization", after all.<br></div></di=
v></blockquote><div><br></div><div>We have identical syntax for aggregation=
and construction as long as they don't conflict. When they do conflict=
, we have different syntaxes to disambiguate. It's your choice whether =
to maximize use of braces and relegate parens to special cases of ambiguity=
, or to generalize the pre-C++11 patterns and use braces for constructors=
=C2=A0only=C2=A0which perform something like conceptual aggregation.<br></d=
iv><div><br></div><div>The term "uniform initialization" was the =
name the original proposal, but it's falling out of use.</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>The motivation is to be abl=
e to do this:<br><br><div style=3D"border:1px solid rgb(187,187,187);word-w=
rap:break-word;background-color:rgb(250,250,250)"><code><div><span style=3D=
"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(102,102,0)">&l=
t;</span><span style=3D"color:rgb(0,0,136)">typename</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">...</span><sp=
an style=3D"color:rgb(102,0,102)">Ts</span><span style=3D"color:rgb(102,102=
,0)">></span><span style=3D"color:rgb(0,0,0)"><br>T emplace</span><span =
style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(102,0,102)"=
>Ts</span><span style=3D"color:rgb(102,102,0)">&&</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">...</spa=
n><span style=3D"color:rgb(0,0,0)">ts</span><span style=3D"color:rgb(102,10=
2,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"co=
lor:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </s=
pan><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rg=
b(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">{</span><span style=
=3D"color:rgb(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)">::</sp=
an><span style=3D"color:rgb(0,0,0)">forward</span><span style=3D"color:rgb(=
102,102,0)"><</span><span style=3D"color:rgb(102,0,102)">Ts</span><span =
style=3D"color:rgb(102,102,0)">>(</span><span style=3D"color:rgb(0,0,0)"=
>ts</span><span style=3D"color:rgb(102,102,0)">)};</span><span style=3D"col=
or:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span><spa=
n style=3D"color:rgb(0,0,0)"><br></span></div></code></div></div></div></bl=
ockquote><div><br></div><div>Maybe that aligns with the original motivation=
, but it's not what current standard emplace members actually do. There=
is a proposal to use braces like that, as a fallback when parens don't=
work.</div><div><br></div><div>If changing it only for emplace and std::al=
locator would be too much, then changing it across the whole language would=
be worse.</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,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Act=
ually, this reminds me of a one-off idea I had at one point to allow `retur=
n <braced-init-list>` to work. I suggested `explicit <braced-init-=
list>`, but `auto {}` could work too.<br></div></div></blockquote><div><=
br></div><div>I remember that too. The difference is just in choice of keyw=
ord, but the connotations are different: auto suggests to deduce something,=
and explicit suggests to adjust constructor lookup.</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);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>We have two problems nowadays with b=
raced-init-lists:<br><br>1) Unable to call explicit constructors without na=
ming the type.<br><br>2) Initializer_list constructors taking priority when=
there is a conflict.<br><br>Having `auto {}` do both of these would probab=
ly be a good idea. I justify joining these two problems because most initia=
lizer_list constructors aren't marked explicit.<br><br>This should also=
allow you to do:<br><br>T t auto{};<br><br>That is, direct-list-initializa=
tion. Again, as a way to bypass initializer_list constructors.<br></div></d=
iv></blockquote><div><br></div><div>Any brace syntax that bypasses initiali=
zer_list would be extremely confusing. Especially one that appears to only =
be pulling in some harmless deduction.</div><div><br></div><div>If it hurts=
when you use braces absolutely everywhere, then don't do that. (The sa=
me goes for Almost Always Auto.) Such rules work well with unsurprising, si=
mple programs. Once one strays from value semantics, the grammatical vocabu=
lary needs to increase. (And besides being new, T t auto{} would be equally=
non-uniform and un-generic as using parens instead of braces!)</div><div><=
br></div><div>For std::vector, for example, there's simply no need to t=
ell a beginner about the constructors other than std::initializer_list. It =
works fine to default-construct and then call resize or insert. If it's=
actually a vector of vectors, then write a loop =E2=80=94 that's actua=
lly <i>more</i>=C2=A0efficient than duplicating a prototype vector. Shortcu=
ts and terseness naturally tend to conflict with uniformity. Maximizing one=
might mean sacrificing the other.</div><div><br></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAAzFsnmKqszwTb2M4be7P9ERT0VBWOdah%2B=
xqRzrswtReXdFfxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAAzFsnmKqszwTb=
2M4be7P9ERT0VBWOdah%2BxqRzrswtReXdFfxw%40mail.gmail.com</a>.<br />
--001a113cddf8ab6dc6052c4171d3--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 21 Feb 2016 09:46:41 -0800 (PST)
Raw View
------=_Part_203_1415270840.1456076802063
Content-Type: multipart/alternative;
boundary="----=_Part_204_1960916739.1456076802064"
------=_Part_204_1960916739.1456076802064
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, February 21, 2016 at 1:01:18 AM UTC-5, David Krauss wrote:
>
> On Sun, Feb 21, 2016 at 5:58 AM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Thursday, February 18, 2016 at 8:59:54 PM UTC-5, David Krauss wrote:
>>>
>>>
>>> Looking back over this thread, I see neither a clear motivation nor a=
=20
>>> mention of the current pattern: Braces tend to represent value aggregat=
ion=20
>>> and parens tend to represent computation by a function.
>>>
>>
>> Is that "the current pattern"? I thought the whole point of having=20
>> braced-init-lists was to allow aggregation and construction to be=20
>> identical. It is called "Uniform Initialization", after all.
>>
>
> We have identical syntax for aggregation and construction as long as they=
=20
> don't conflict. When they do conflict, we have different syntaxes to=20
> disambiguate. It's your choice whether to maximize use of braces and=20
> relegate parens to special cases of ambiguity, or to generalize the=20
> pre-C++11 patterns and use braces for constructors only which perform=20
> something like conceptual aggregation.
>
If you design a feature to do X, but then you find that it doesn't do X,=20
you call that feature "broken". The correct response is to *fix* the=20
feature.
The incorrect response is to pretend we really meant for it to do Y.=20
Especially when *we still need X*.
Because of this broken part of uniform initialization, we've made=20
initialization *more complicated*. This is the *exact opposite of the goal*=
..
Take your "conceptual aggregation" rule. Even if we all agreed on what that=
=20
means, you still can't use it in generic code, because whether a type is=20
"conceptual aggregation" or not is not something that can be deduced (we=20
don't even have an `is_aggregate` trait). Even if we ignore that, there's=
=20
still one insurmountable problem:
If your type isn't involved in "conceptual aggregation", then your type is =
*still=20
at risk* for the most vexing parse. You know, the primary impetus for us=20
creating a whole new initialization scheme.
So I would say that this "conceptual aggregation" rule is broken.
We still need X.
We have two problems nowadays with braced-init-lists:
>>
>> 1) Unable to call explicit constructors without naming the type.
>>
>> 2) Initializer_list constructors taking priority when there is a conflic=
t.
>>
>> Having `auto {}` do both of these would probably be a good idea. I=20
>> justify joining these two problems because most initializer_list=20
>> constructors aren't marked explicit.
>>
>> This should also allow you to do:
>>
>> T t auto{};
>>
>> That is, direct-list-initialization. Again, as a way to bypass=20
>> initializer_list constructors.
>>
>
> Any brace syntax that bypasses initializer_list would be extremely=20
> confusing.
>
To whom?
Especially one that appears to only be pulling in some harmless deduction.
>
> If it hurts when you use braces absolutely everywhere, then don't do that=
..
>
So, if the encryption in your server is easily cracked, the response should=
=20
be "don't encrypt your server with our product"? We got a buggy feature in=
=20
C++11. The correct answer is not to claim that it's the user's fault for *f=
inding=20
the bug*.
The correct answer is to fix the feature, not pretend that the bug was=20
intended.
(The same goes for Almost Always Auto.)
>
Again, you could just fix the language.
=20
> Such rules work well with unsurprising, simple programs. Once one strays=
=20
> from value semantics, the grammatical vocabulary needs to increase. (And=
=20
> besides being new, T t auto{} would be equally non-uniform and un-generic=
=20
> as using parens instead of braces!)
>
Exactly how would it be non-uniform? Every type T which is default=20
constructible can have its default constructor called with that syntax.=20
Whether T is an aggregate or a non-aggregate, this will work.
T t auto{5, 3};
Will always either perform aggregate initialization or call a constructor=
=20
of T that takes 2 parameters. If T has no such constructor, or it cannot be=
=20
aggregate initialized from those parameters, then it will fail. Therefore,=
=20
it is a concept of such a generic function that the T be constructible with=
=20
`auto{5, 3}`.
The problem with doing `T t{5, 3}` is that you don't know if `T` has an=20
initializer list constructor that takes integers. If it does, then this=20
will almost certainly do the wrong thing. Do you see the point? It's=20
"non-uniform and un-generic" only because it is calling the wrong function.
There is no reason why we can't have one initialization syntax that always=
=20
aggregate/constructor initializes in every case. We simply didn't get that=
=20
in C++11, because of the bad decision to prioritize initializer_list=20
constructors. And that was only done because we combined uniform=20
initialization syntax (which Bjarne proposed) with the initializer_list=20
proposal, all just so that people could avoid having to write an extra set=
=20
of braces for array-like initialization.
I honestly don't care if it uses `auto`, `explicit`, `{. stuff}` or=20
whatever. There is a need to be able to direct-list-initialize/aggregate=20
initialize that *will not prioritize* initializer_list constructors.
For std::vector, for example, there's simply no need to tell a beginner=20
> about the constructors other than std::initializer_list. It works fine to=
=20
> default-construct and then call resize or insert. If it's actually a vect=
or=20
> of vectors, then write a loop =E2=80=94 that's actually *more* efficient =
than=20
> duplicating a prototype vector. Shortcuts and terseness naturally tend to=
=20
> conflict with uniformity. Maximizing one might mean sacrificing the other=
..
>
Nonsense. If uniform initialization had been done correctly, if it had been=
=20
made uniform, we wouldn't have to sacrifice *anything*. Creating an array=
=20
with a vector would simply be `vector<int> v =3D {{1, 2, 3}};` One set of=
=20
extra brackets makes all the difference. If that had been how C++11=20
shipped, people would simply have gotten used to using the double braces=20
for that. Generic could would be able to distinguish between constructor=20
initialization and initializer list initialization.
It would have been uniform initialization.
We also wouldn't need special brace-elision rules to make `array<int, 3> a=
=20
=3D {1, 2, 3};` work. The only place where you wouldn't use a double-brace=
=20
would be an actual language array. And people should just stop using those=
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b108df13-c07b-4453-be91-8461a703b12c%40isocpp.or=
g.
------=_Part_204_1960916739.1456076802064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 21, 2016 at 1:01:18 AM UTC-5, David Kr=
auss 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"><d=
iv><div class=3D"gmail_quote">On Sun, Feb 21, 2016 at 5:58 AM, Nicol Bolas =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"LSDYstBEAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote cla=
ss=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">On Thursday, February 18, 2016 at 8:59:54 PM UTC-5, Davi=
d Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><sp=
an><div>Looking back over this thread, I see neither a clear motivation nor=
a mention of the current pattern: Braces tend to represent value aggregati=
on and parens tend to represent computation by a function.</div></span></di=
v></blockquote><div><br>Is that "the current pattern"? I thought =
the whole point of having braced-init-lists was to allow aggregation and co=
nstruction to be identical. It is called "Uniform Initialization"=
, after all.<br></div></div></blockquote><div><br></div><div>We have identi=
cal syntax for aggregation and construction as long as they don't confl=
ict. When they do conflict, we have different syntaxes to disambiguate. It&=
#39;s your choice whether to maximize use of braces and relegate parens to =
special cases of ambiguity, or to generalize the pre-C++11 patterns and use=
braces for constructors=C2=A0only=C2=A0which perform something like concep=
tual aggregation.<br></div></div></div></div></blockquote><div><br>If you d=
esign a feature to do X, but then you find that it doesn't do X, you ca=
ll that feature "broken". The correct response is to <i>fix</i> t=
he feature.<br><br>The incorrect response is to pretend we really meant for=
it to do Y. Especially when <i>we still need X</i>.<br><br>Because of this=
broken part of uniform initialization, we've made initialization <i>mo=
re complicated</i>. This is the <i>exact opposite of the goal</i>.<br><br>T=
ake your "conceptual aggregation" rule. Even if we all agreed on =
what that means, you still can't use it in generic code, because whethe=
r a type is "conceptual aggregation" or not is not something that=
can be deduced (we don't even have an `is_aggregate` trait). Even if w=
e ignore that, there's still one insurmountable problem:<br><br>If your=
type isn't involved in "conceptual aggregation", then your t=
ype is <i>still at risk</i> for the most vexing parse. You know, the primar=
y impetus for us creating a whole new initialization scheme.<br><br>So I wo=
uld say that this "conceptual aggregation" rule is broken.<br><br=
>We still need X.<br></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 dir=3D"ltr"><div><div></div></div></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div></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>We have two=
problems nowadays with braced-init-lists:<br><br>1) Unable to call explici=
t constructors without naming the type.<br><br>2) Initializer_list construc=
tors taking priority when there is a conflict.<br><br>Having `auto {}` do b=
oth of these would probably be a good idea. I justify joining these two pro=
blems because most initializer_list constructors aren't marked explicit=
..<br><br>This should also allow you to do:<br><br>T t auto{};<br><br>That i=
s, direct-list-initialization. Again, as a way to bypass initializer_list c=
onstructors.<br></div></div></blockquote><div><br></div><div>Any brace synt=
ax that bypasses initializer_list would be extremely confusing.</div></div>=
</div></div></blockquote><div><br>To whom?<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div> Especially one that appears to only be pulling in some harmless ded=
uction.</div><div><br></div><div>If it hurts when you use braces absolutely=
everywhere, then don't do that.</div></div></div></div></blockquote><d=
iv><br>So, if the encryption in your server is easily cracked, the response=
should be "don't encrypt your server with our product"? We g=
ot a buggy feature in C++11. The correct answer is not to claim that it'=
;s the user's fault for <i>finding the bug</i>.<br><br>The correct answ=
er is to fix the feature, not pretend that the bug was intended.<br><br></d=
iv><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><div =
class=3D"gmail_quote"><div> (The same goes for Almost Always Auto.)</div></=
div></div></div></blockquote><div><br>Again, you could just fix the languag=
e.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div>Such rules work well with unsurpr=
ising, simple programs. Once one strays from value semantics, the grammatic=
al vocabulary needs to increase. (And besides being new, T t auto{} would b=
e equally non-uniform and un-generic as using parens instead of braces!)</d=
iv></div></div></div></blockquote><div><br>Exactly how would it be non-unif=
orm? Every type T which is default constructible can have its default const=
ructor called with that syntax. Whether T is an aggregate or a non-aggregat=
e, this will work.<br><br>T t auto{5, 3};<br><br>Will always either perform=
aggregate initialization or call a constructor of T that takes 2 parameter=
s. If T has no such constructor, or it cannot be aggregate initialized from=
those parameters, then it will fail. Therefore, it is a concept of such a =
generic function that the T be constructible with `auto{5, 3}`.<br><br>The =
problem with doing `T t{5, 3}` is that you don't know if `T` has an ini=
tializer list constructor that takes integers. If it does, then this will a=
lmost certainly do the wrong thing. Do you see the point? It's "no=
n-uniform and un-generic" only because it is calling the wrong functio=
n.<br><br>There is no reason why we can't have one initialization synta=
x that always aggregate/constructor initializes in every case. We simply di=
dn't get that in C++11, because of the bad decision to prioritize initi=
alizer_list constructors. And that was only done because we combined unifor=
m initialization syntax (which Bjarne proposed) with the initializer_list p=
roposal, all just so that people could avoid having to write an extra set o=
f braces for array-like initialization.<br><br></div><div>I honestly don=
9;t care if it uses `auto`, `explicit`, `{. stuff}` or whatever. There is a=
need to be able to direct-list-initialize/aggregate initialize that <i>wil=
l not prioritize</i> initializer_list constructors.<br><br></div><blockquot=
e 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><div class=3D"gmai=
l_quote"><div></div><div>For std::vector, for example, there's simply n=
o need to tell a beginner about the constructors other than std::initialize=
r_list. It works fine to default-construct and then call resize or insert. =
If it's actually a vector of vectors, then write a loop =E2=80=94 that&=
#39;s actually <i>more</i>=C2=A0efficient than duplicating a prototype vect=
or. Shortcuts and terseness naturally tend to conflict with uniformity. Max=
imizing one might mean sacrificing the other.</div></div></div></div></bloc=
kquote><div><br>Nonsense. If uniform initialization had been done correctly=
, if it had been made uniform, we wouldn't have to sacrifice <i>anythin=
g</i>. Creating an array with a vector would simply be `vector<int> v=
=3D {{1, 2, 3}};` One set of extra brackets makes all the difference. If t=
hat had been how C++11 shipped, people would simply have gotten used to usi=
ng the double braces for that. Generic could would be able to distinguish b=
etween constructor initialization and initializer list initialization.<br><=
br>It would have been uniform initialization.<br><br>We also wouldn't n=
eed special brace-elision rules to make `array<int, 3> a =3D {1, 2, 3=
};` work. The only place where you wouldn't use a double-brace would be=
an actual language array. And people should just stop using those ;)<br></=
div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b108df13-c07b-4453-be91-8461a703b12c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b108df13-c07b-4453-be91-8461a703b12c=
%40isocpp.org</a>.<br />
------=_Part_204_1960916739.1456076802064--
------=_Part_203_1415270840.1456076802063--
.
Author: =?UTF-8?Q?P=C3=A9ter_Radics?= <mitchnull@gmail.com>
Date: Mon, 22 Feb 2016 00:37:59 -0800 (PST)
Raw View
------=_Part_8548_2039098257.1456130279892
Content-Type: multipart/alternative;
boundary="----=_Part_8549_2135456825.1456130279892"
------=_Part_8549_2135456825.1456130279892
Content-Type: text/plain; charset=UTF-8
>
> Nonsense. If uniform initialization had been done correctly, if it had
> been made uniform, we wouldn't have to sacrifice *anything*. Creating an
> array with a vector would simply be `vector<int> v = {{1, 2, 3}};` One set
> of extra brackets makes all the difference. If that had been how C++11
> shipped, people would simply have gotten used to using the double braces
> for that. Generic could would be able to distinguish between constructor
> initialization and initializer list initialization.
>
> It would have been uniform initialization.
>
> We also wouldn't need special brace-elision rules to make `array<int, 3> a
> = {1, 2, 3};` work. The only place where you wouldn't use a double-brace
> would be an actual language array. And people should just stop using those
> ;)
>
Agreed (almost) completely: I would go so far as to fix the syntax even by
a breaking change: use the most natural syntax for the most
common/important thing (uniform initialization), and use {{ }} for
initializer_list ctors as Nicol described above. Don't introduce additional
clutter (auto {}, etc) as a "fix" :(
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d7fc84d6-6cc4-41ac-8bfe-724aba26cfed%40isocpp.org.
------=_Part_8549_2135456825.1456130279892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><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"><div>Nonsense. If uniform initialization had been done correctly, if it=
had been made uniform, we wouldn't have to sacrifice <i>anything</i>. =
Creating an array with a vector would simply be `vector<int> v =3D {{=
1, 2, 3}};` One set of extra brackets makes all the difference. If that had=
been how C++11 shipped, people would simply have gotten used to using the =
double braces for that. Generic could would be able to distinguish between =
constructor initialization and initializer list initialization.<br><br>It w=
ould have been uniform initialization.<br><br>We also wouldn't need spe=
cial brace-elision rules to make `array<int, 3> a =3D {1, 2, 3};` wor=
k. The only place where you wouldn't use a double-brace would be an act=
ual language array. And people should just stop using those ;)<br></div></d=
iv></blockquote><div><br></div><div>Agreed (almost) completely: I would go =
so far as to fix the syntax even by a breaking change: use the most natural=
syntax for the most common/important thing (uniform initialization), and u=
se {{ }} for initializer_list ctors as Nicol described above. Don't int=
roduce additional clutter (auto {}, etc) as a "fix" :(</div><div>=
=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d7fc84d6-6cc4-41ac-8bfe-724aba26cfed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d7fc84d6-6cc4-41ac-8bfe-724aba26cfed=
%40isocpp.org</a>.<br />
------=_Part_8549_2135456825.1456130279892--
------=_Part_8548_2039098257.1456130279892--
.