------=_Part_14787_415954940.1515428196693
Content-Type: multipart/alternative;
 boundary="----=_Part_14788_1175322597.1515428196693"

------=_Part_14788_1175322597.1515428196693
Content-Type: text/plain; charset="UTF-8"

Hello Folks,

currently, *std::allocator* (and* std::allocator_traits*) use value
initialization, that is placement *new (p) ()*.
..
However, this prevents it from initializing aggregates (see here
<https://godbolt.org/g/SczDmR>).

Since using uniform initialization is the recommended (as of C++14) way of
initializing variables, *std::allocator* and *std::allocator_traits* should
follow this guideline.
I think, we can all agree, that in general, not being able to emplace()
aggregates is an incompleteness.

There might be several downsides to this. I have found the following one:

   - it breaks implicit narrowing conversions not possible with uniform
   initialization

What are your thoughts on this?
How to fix this the best way? Should we fix it?

One possible (maybe not desired) solution is to SFINAE-overload
*new(p)(...)* with *new(p){...} *inside *::construct()*, preferring the
latter if viable.

I look forward to hearing from you!

Cheers,
Jakob

--
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/0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40%40isocpp.org.

------=_Part_14788_1175322597.1515428196693
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Folks,<div><br></div><div>currently, <b>std::allocat=
or</b> (and<b> std::allocator_traits</b>) use value initialization, that is=
 placement <b>new (p) ()</b>.<br>.</div><div>However, this prevents it from=
 initializing aggregates (see <a href=3D"https://godbolt.org/g/SczDmR">here=
</a>).</div><div><br></div><div>Since using uniform initialization is the r=
ecommended (as of C++14) way of initializing variables, <b>std::allocator</=
b> and <b>std::allocator_traits</b> should follow this guideline.</div><div=
>I think, we can all agree, that in general, not being able to emplace() ag=
gregates is an incompleteness.<br></div><div><br></div><div>There might be =
several downsides to this. I have found the following one:</div><div><ul><l=
i>it breaks implicit narrowing conversions not possible with uniform initia=
lization</li></ul>What are your thoughts on this?</div><div>How to fix this=
 the best way? Should we fix it?</div><div><br></div><div>One possible (may=
be not desired) solution is to SFINAE-overload <b>new(p)(...)</b> with <b>n=
ew(p){...} </b>inside <b>::construct()</b>, preferring the latter if viable=
..</div><div><br></div><div>I look forward to hearing from you!</div><div><b=
r></div><div>Cheers,</div><div>Jakob</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40=
%40isocpp.org</a>.<br />

------=_Part_14788_1175322597.1515428196693--

------=_Part_14787_415954940.1515428196693--

.

------=_Part_14607_1502439270.1515428728281
Content-Type: multipart/alternative;
 boundary="----=_Part_14608_199337935.1515428728281"

------=_Part_14608_199337935.1515428728281
Content-Type: text/plain; charset="UTF-8"



On Monday, January 8, 2018 at 11:16:36 AM UTC-5, Jakob Riedle wrote:
>
> Hello Folks,
>
> currently, *std::allocator* (and* std::allocator_traits*) use value
> initialization, that is placement *new (p) ()*.
> .
> However, this prevents it from initializing aggregates (see here
> <https://godbolt.org/g/SczDmR>).
>
> Since using uniform initialization is the recommended (as of C++14) way of
> initializing variables,
>

Recommended by whom? It's* broken*. Uniform initialization can hide
constructors. Its narrowing restrictions,* especially* with forwarded
argument, play havoc with initialization.

Uniform initialization is good syntax bound to bad initialization rules. It
is not some default recommendation for initializing variables.


> *std::allocator* and *std::allocator_traits* should follow this guideline.
> I think, we can all agree, that in general, not being able to emplace()
> aggregates is an incompleteness.
>

Yes. That's why LWG-2089 exists
<http://cplusplus.github.io/LWG/lwg-active.html#2089>. I've written
something
<https://github.com/NicolBolas/Proposal-Ideas/blob/master/Towards%20a%20Fix%20For%20LWG%202089.md>
that covers the proposed solution, corrects it, and thoroughly investigates
all of the issues around it and pretty much every possible language and
library solutions.

And if you have another possible solution not on that list, please let me
know.

--
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/ad3e7a1f-eba9-4395-9ea1-2b4852fc921a%40isocpp.org.

------=_Part_14608_199337935.1515428728281
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 8, 2018 at 11:16:36 AM UTC-5, J=
akob Riedle wrote:<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">Hello Folks,<div><br></div><div>currently, <b>std::allocator</b> (and<=
b> std::allocator_traits</b>) use value initialization, that is placement <=
b>new (p) ()</b>.<br>.</div><div>However, this prevents it from initializin=
g aggregates (see <a onmousedown=3D"this.href=3D&#39;https://www.google.com=
/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FSczDmR\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNGI1vF5m3odAolQRxFRsf2a-Vr2mQ&#39;;return true;" onclick=3D"th=
is.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2F=
g%2FSczDmR\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGI1vF5m3odAolQRxFRsf2a-V=
r2mQ&#39;;return true;" href=3D"https://godbolt.org/g/SczDmR" target=3D"_bl=
ank" rel=3D"nofollow">here</a>).</div><div><br></div><div>Since using unifo=
rm initialization is the recommended (as of C++14) way of initializing vari=
ables,</div></div></blockquote><div><br></div><div>Recommended by whom? It&=
#39;s<i> broken</i>. Uniform initialization can hide constructors. Its narr=
owing restrictions,<i> especially</i> with forwarded argument, play havoc w=
ith initialization.</div><div><br></div><div>Uniform initialization is good=
 syntax bound to bad initialization rules. It is not some default recommend=
ation for initializing variables.</div><div><i></i>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div> <b>std::allocator</=
b> and <b>std::allocator_traits</b> should follow this guideline.</div><div=
>I think, we can all agree, that in general, not being able to emplace() ag=
gregates is an incompleteness.<br></div></div></blockquote><div><br></div><=
div>Yes. That&#39;s why <a href=3D"http://cplusplus.github.io/LWG/lwg-activ=
e.html#2089">LWG-2089 exists</a>. I&#39;ve <a href=3D"https://github.com/Ni=
colBolas/Proposal-Ideas/blob/master/Towards%20a%20Fix%20For%20LWG%202089.md=
">written something</a> that covers the proposed solution, corrects it, and=
 thoroughly investigates all of the issues around it and pretty much every =
possible language and library solutions.</div><div><br></div><div>And if yo=
u have another possible solution not on that list, please let me know.</div=
><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ad3e7a1f-eba9-4395-9ea1-2b4852fc921a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad3e7a1f-eba9-4395-9ea1-2b4852fc921a=
%40isocpp.org</a>.<br />

------=_Part_14608_199337935.1515428728281--

------=_Part_14607_1502439270.1515428728281--

.

On 8 January 2018 at 18:25, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Monday, January 8, 2018 at 11:16:36 AM UTC-5, Jakob Riedle wrote:
>>
>> Hello Folks,
>>
>> currently, std::allocator (and std::allocator_traits) use value
>> initialization, that is placement new (p) ().
>> .
>> However, this prevents it from initializing aggregates (see here).
>>
>> Since using uniform initialization is the recommended (as of C++14) way of
>> initializing variables,
>
>
> Recommended by whom? It's broken. Uniform initialization can hide
> constructors. Its narrowing restrictions, especially with forwarded
> argument, play havoc with initialization.
>
> Uniform initialization is good syntax bound to bad initialization rules. It
> is not some default recommendation for initializing variables.
>
>>
>> std::allocator and std::allocator_traits should follow this guideline.
>> I think, we can all agree, that in general, not being able to emplace()
>> aggregates is an incompleteness.
>
>
> Yes. That's why LWG-2089 exists. I've written something that covers the
> proposed solution, corrects it, and thoroughly investigates all of the
> issues around it and pretty much every possible language and library
> solutions.
>
> And if you have another possible solution not on that list, please let me
> know.


I plan to propose allowing paren-initializing aggregates. That
proposal should appear in the pre-Jacksonville
mailing.

--
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/CAFk2RUbtYTmHWvwWGUgaL8%3DJgOhDz8W4CRio7Xq62nYt2oMhtg%40mail.gmail.com.

.

------=_Part_14999_901955929.1515435027671
Content-Type: multipart/alternative;
 boundary="----=_Part_15000_1409491456.1515435027671"

------=_Part_15000_1409491456.1515435027671
Content-Type: text/plain; charset="UTF-8"



On Monday, January 8, 2018 at 12:25:18 PM UTC-5, Ville Voutilainen wrote:
>
> On 8 January 2018 at 18:25, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> >
> > On Monday, January 8, 2018 at 11:16:36 AM UTC-5, Jakob Riedle wrote:
> >>
> >> Hello Folks,
> >>
> >> currently, std::allocator (and std::allocator_traits) use value
> >> initialization, that is placement new (p) ().
> >> .
> >> However, this prevents it from initializing aggregates (see here).
> >>
> >> Since using uniform initialization is the recommended (as of C++14) way
> of
> >> initializing variables,
> >
> >
> > Recommended by whom? It's broken. Uniform initialization can hide
> > constructors. Its narrowing restrictions, especially with forwarded
> > argument, play havoc with initialization.
> >
> > Uniform initialization is good syntax bound to bad initialization rules.
> It
> > is not some default recommendation for initializing variables.
> >
> >>
> >> std::allocator and std::allocator_traits should follow this guideline.
> >> I think, we can all agree, that in general, not being able to emplace()
> >> aggregates is an incompleteness.
> >
> >
> > Yes. That's why LWG-2089 exists. I've written something that covers the
> > proposed solution, corrects it, and thoroughly investigates all of the
> > issues around it and pretty much every possible language and library
> > solutions.
> >
> > And if you have another possible solution not on that list, please let
> me
> > know.
>
>
> I plan to propose allowing paren-initializing aggregates. That
> proposal should appear in the pre-Jacksonville
> mailing.
>

Please,* please* make it turn off narrowing prevention!


--
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/0b33061f-3b5a-481f-849b-3c7da72897db%40isocpp.org.

------=_Part_15000_1409491456.1515435027671
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, January 8, 2018 at 12:25:18 PM UTC-5, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 8 Ja=
nuary 2018 at 18:25, Nicol Bolas &lt;<a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"X-W4NBQqAAAJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Monday, January 8, 2018 at 11:16:36 AM UTC-5, Jakob Riedle wrot=
e:
<br>&gt;&gt;
<br>&gt;&gt; Hello Folks,
<br>&gt;&gt;
<br>&gt;&gt; currently, std::allocator (and std::allocator_traits) use valu=
e
<br>&gt;&gt; initialization, that is placement new (p) ().
<br>&gt;&gt; .
<br>&gt;&gt; However, this prevents it from initializing aggregates (see he=
re).
<br>&gt;&gt;
<br>&gt;&gt; Since using uniform initialization is the recommended (as of C=
++14) way of
<br>&gt;&gt; initializing variables,
<br>&gt;
<br>&gt;
<br>&gt; Recommended by whom? It&#39;s broken. Uniform initialization can h=
ide
<br>&gt; constructors. Its narrowing restrictions, especially with forwarde=
d
<br>&gt; argument, play havoc with initialization.
<br>&gt;
<br>&gt; Uniform initialization is good syntax bound to bad initialization =
rules. It
<br>&gt; is not some default recommendation for initializing variables.
<br>&gt;
<br>&gt;&gt;
<br>&gt;&gt; std::allocator and std::allocator_traits should follow this gu=
ideline.
<br>&gt;&gt; I think, we can all agree, that in general, not being able to =
emplace()
<br>&gt;&gt; aggregates is an incompleteness.
<br>&gt;
<br>&gt;
<br>&gt; Yes. That&#39;s why LWG-2089 exists. I&#39;ve written something th=
at covers the
<br>&gt; proposed solution, corrects it, and thoroughly investigates all of=
 the
<br>&gt; issues around it and pretty much every possible language and libra=
ry
<br>&gt; solutions.
<br>&gt;
<br>&gt; And if you have another possible solution not on that list, please=
 let me
<br>&gt; know.
<br>
<br>
<br>I plan to propose allowing paren-initializing aggregates. That
<br>proposal should appear in the pre-Jacksonville
<br>mailing.
<br></blockquote><div><br></div><div>Please,<i> please</i> make it turn off=
 narrowing prevention!</div><div><i></i>=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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0b33061f-3b5a-481f-849b-3c7da72897db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0b33061f-3b5a-481f-849b-3c7da72897db=
%40isocpp.org</a>.<br />

------=_Part_15000_1409491456.1515435027671--

------=_Part_14999_901955929.1515435027671--

.

------=_Part_8313_1045594467.1515435947922
Content-Type: multipart/alternative;
 boundary="----=_Part_8314_757833529.1515435947923"

------=_Part_8314_757833529.1515435947923
Content-Type: text/plain; charset="UTF-8"

Am Montag, 8. Januar 2018 17:25:28 UTC+1 schrieb Nicol Bolas:
>
> Yes. That's why LWG-2089 exists
> <http://cplusplus.github.io/LWG/lwg-active.html#2089>. I've written
> something
> <https://github.com/NicolBolas/Proposal-Ideas/blob/master/Towards%20a%20Fix%20For%20LWG%202089.md>
> that covers the proposed solution, corrects it, and thoroughly investigates
> all of the issues around it and pretty much every possible language and
> library solutions.
>
Yay! I was hoping for something like this, but couldn't find anything.
Thank you!


> And if you have another possible solution not on that list, please let me
> know.
>
The solution proposed is, what I would have expected.

Jakob

--
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/8923127b-fa97-46dd-9010-9a950f799eb2%40isocpp.org.

------=_Part_8314_757833529.1515435947923
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Am Montag, 8. Januar 2018 17:25:28 UTC+1 schrieb Nicol Bol=
as:<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>Yes. =
That&#39;s why <a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#20=
89" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-act=
ive.html%232089\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHfYo86LETvfuC9SJHAf=
CohX1GL6g&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fcplusplus.github.io%2FLWG%2Flwg-active.html%23208=
9\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHfYo86LETvfuC9SJHAfCohX1GL6g&#39;=
;return true;">LWG-2089 exists</a>. I&#39;ve <a href=3D"https://github.com/=
NicolBolas/Proposal-Ideas/blob/master/Towards%20a%20Fix%20For%20LWG%202089.=
md" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
s://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FNicolBolas%2FProposa=
l-Ideas%2Fblob%2Fmaster%2FTowards%2520a%2520Fix%2520For%2520LWG%25202089.md=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSOJF53UOo1xtfQ31GsY2oTBy39g&#39;;=
return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dh=
ttps%3A%2F%2Fgithub.com%2FNicolBolas%2FProposal-Ideas%2Fblob%2Fmaster%2FTow=
ards%2520a%2520Fix%2520For%2520LWG%25202089.md\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNGSOJF53UOo1xtfQ31GsY2oTBy39g&#39;;return true;">written somethi=
ng</a> that covers the proposed solution, corrects it, and thoroughly inves=
tigates all of the issues around it and pretty much every possible language=
 and library solutions.</div></div></blockquote><div>Yay! I was hoping for =
something like this, but couldn&#39;t find anything.</div><div>Thank you!</=
div><div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div></div><div>And if you have another possible solution not=
 on that list, please let me know.</div></div></blockquote><div>The solutio=
n proposed is, what I would have expected.</div><div><br></div><div>Jakob</=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8923127b-fa97-46dd-9010-9a950f799eb2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8923127b-fa97-46dd-9010-9a950f799eb2=
%40isocpp.org</a>.<br />

------=_Part_8314_757833529.1515435947923--

------=_Part_8313_1045594467.1515435947922--

.

On 8 January 2018 at 20:10, Nicol Bolas <jmckesson@gmail.com> wrote:
>> I plan to propose allowing paren-initializing aggregates. That
>> proposal should appear in the pre-Jacksonville
>> mailing.
>
>
> Please, please make it turn off narrowing prevention!


I will include that consideration, thanks; I am not hell-bent on it
either way - there's some value in having
paren-initializing aggregates mean exactly the same thing as
brace-initializing them, but there's also some
value in having paren-init not prevent narrowing. Turning off
narrowing prevention makes some sense to me, but
I can live without it. I can also easily imagine some user somewhere
saying "no, don't do that, I intentionally
left out constructors with the expectation that my type can *not* be
initialized with narrowing conversions,
and just because it can now be initialized with a syntax that wasn't
ok before should not change that without
my opt-in". ;)

--
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/CAFk2RUZB4PvoRpwu%2Bp%3Dyq%3DuwPky9mibEy%2B1ZVoTBYxa58uPwcg%40mail.gmail.com.

.