------=_Part_1615_22411029.1377501415263
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=B3ek, 26 sierpnia 2013 07:48:50 UTC+2 u=BFytkownik Johanne=
s=20
Schaub napisa=B3:
>
> Sometimes I wonder whether one should be able to declare that one=20
> constructor (which probably should not be declared "explicit") should not=
=20
> consume braces
>
>     struct Variant {
>       Variant(std::map<int, int>);
>       Variant(std::vector<string>);
>     };
>
>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
>
> It being a variant, containing the value of either a vector ("list of=20
> ints") or a map ("map of one to another int"), I find it just intuitive=
=20
> that one should be able to list initialize it with "{1, 2, 3}". However,=
=20
> the constructor consomes the outer brace. I think the implication here is=
=20
> that the constructor constructs a value which "wraps" something. I this=
=20
> case it seems however that this makes things more complicated to the user=
,=20
> since they have to remember how many braces to put.=20
>
> What about making an opportunity to mark them as an initializer=20
> constructor?=20
>
>     struct Variant {
>       continue Variant(std::map<int, int>);
>       continue Variant(std::vector<string>);
>     };
>

Somewhat dodging your proposal, I think the following class design would=20
fix the problem for the users:

struct Variant
{
    Variant(std::initializer_list<std::pair<int, int>>);
    Variant(std::initializer_list<int>);
};

And I think the interface is still (self explanatory) clear enough. Of=20
course, you need a third constructor to tell what the following=20
initialization means:

Variant v{};

Regards,
&rzej

--=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_1615_22411029.1377501415263
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=B3ek, 26 sierpnia 2013 07:48:50 U=
TC+2 u=BFytkownik Johannes Schaub napisa=B3:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">Sometimes I wonder whether one should be abl=
e to declare that one constructor (which probably should not be declared "e=
xplicit") should not consume braces<div><br></div><div>&nbsp; &nbsp; struct=
 Variant {</div><div>&nbsp; &nbsp; &nbsp; Variant(std::map&lt;int, int&gt;)=
;</div><div>&nbsp; &nbsp; &nbsp; Variant(std::vector&lt;string&gt;);</div><=
div>&nbsp; &nbsp; };</div><div><br></div><div>&nbsp; &nbsp; Variant v{{1, 2=
}, {3, 4}}; // unfortunately, ill-formed!</div><div>&nbsp; &nbsp; Variant v=
2{1, 2, 3}; // unfortunately, ill-formed!</div><div><br></div><div>It being=
 a variant, containing the value of either a vector ("list of ints") or a m=
ap ("map of one to another int"), I find it just intuitive that one should =
be able to list initialize it with "{1, 2, 3}". However, the constructor co=
nsomes the outer brace. I think the implication here is that the constructo=
r constructs a value which "wraps" something. I this case it seems however =
that this makes things more complicated to the user, since they have to rem=
ember how many braces to put.&nbsp;</div><div><br></div><div>What about mak=
ing an opportunity to mark them as an initializer constructor?&nbsp;</div><=
div><br></div><div><div>&nbsp; &nbsp; struct Variant {</div><div>&nbsp; &nb=
sp; &nbsp; continue Variant(std::map&lt;int, int&gt;);</div><div>&nbsp; &nb=
sp; &nbsp; continue Variant(std::vector&lt;string&gt;);</div><div>&nbsp; &n=
bsp; };</div></div></div></blockquote><div><br>Somewhat dodging your propos=
al, I think the following class design would fix the problem for the users:=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">stru=
ct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Variant</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Variant</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">initializer_list</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">pair</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;&gt;);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Variant</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">initializer_list</span><span style=3D"color: #080;"=
 class=3D"styled-by-prettify">&lt;int&gt;</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 style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>And I think the interface is st=
ill (self explanatory) clear enough. Of course, you need a third constructo=
r to tell what the following initialization means:<br><br><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Variant</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span></div></code></div><br>Regards,<br>=
&amp;rzej<br><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1615_22411029.1377501415263--

.

2013/8/26 Andrzej Krzemie=C5=84ski <akrzemi1@gmail.com>:
> Somewhat dodging your proposal, I think the following class design would =
fix
> the problem for the users:
>
> struct Variant
> {
>     Variant(std::initializer_list<std::pair<int, int>>);
>     Variant(std::initializer_list<int>);
> };
>
> And I think the interface is still (self explanatory) clear enough. Of
> course, you need a third constructor to tell what the following
> initialization means:
>
> Variant v{};

In fact you don't even need a third constructor, you can instead
provide a default argument to one of the above ones, e.g.

struct Variant
{
    Variant(std::initializer_list<std::pair<int, int>>);
    Variant(std::initializer_list<int> =3D {});
};

- Daniel

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

.

--047d7b15a465409cbd04e4d5d22f
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Am 26.08.2013 09:16 schrieb "Andrzej Krzemie=F1ski" <akrzemi1@gmail.com>:
>
>
>
> W dniu poniedzia=B3ek, 26 sierpnia 2013 07:48:50 UTC+2 u=BFytkownik Johan=
nes
Schaub napisa=B3:
>>
>> Sometimes I wonder whether one should be able to declare that one
constructor (which probably should not be declared "explicit") should not
consume braces
>>
>>     struct Variant {
>>       Variant(std::map<int, int>);
>>       Variant(std::vector<string>);
>>     };
>>
>>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
>>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
>>
>> It being a variant, containing the value of either a vector ("list of
ints") or a map ("map of one to another int"), I find it just intuitive
that one should be able to list initialize it with "{1, 2, 3}". However,
the constructor consomes the outer brace. I think the implication here is
that the constructor constructs a value which "wraps" something. I this
case it seems however that this makes things more complicated to the user,
since they have to remember how many braces to put.
>>
>> What about making an opportunity to mark them as an initializer
constructor?
>>
>>     struct Variant {
>>       continue Variant(std::map<int, int>);
>>       continue Variant(std::vector<string>);
>>     };
>
>
> Somewhat dodging your proposal, I think the following class design would
fix the problem for the users:
>
> struct Variant
> {
>     Variant(std::initializer_list<std::pair<int, int>>);
>     Variant(std::initializer_list<int>);
> };
>
> And I think the interface is still (self explanatory) clear enough. Of
course, you need a third constructor to tell what the following
initialization means:
>

This is a reasonable nongeneric solution. For classes like optional or
variant, it would need to detect the element type somehow (relying on a
typedef?).

Anyhow, i will make it one more difficult

    struct optional {
       continue optional(pair <int, int>);
    };

What options/workarounds are there to make this valid?

   optional o {a, b};

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

--047d7b15a465409cbd04e4d5d22f
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Am 26.08.2013 09:16 schrieb &quot;Andrzej Krzemie=F1ski&quot; &lt;<a href=
=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; W dniu poniedzia=B3ek, 26 sierpnia 2013 07:48:50 UTC+2 u=BFytkownik Jo=
hannes Schaub napisa=B3:<br>
&gt;&gt;<br>
&gt;&gt; Sometimes I wonder whether one should be able to declare that one =
constructor (which probably should not be declared &quot;explicit&quot;) sh=
ould not consume braces<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 struct Variant {<br>
&gt;&gt; =A0 =A0 =A0 Variant(std::map&lt;int, int&gt;);<br>
&gt;&gt; =A0 =A0 =A0 Variant(std::vector&lt;string&gt;);<br>
&gt;&gt; =A0 =A0 };<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!<b=
r>
&gt;&gt; =A0 =A0 Variant v2{1, 2, 3}; // unfortunately, ill-formed!<br>
&gt;&gt;<br>
&gt;&gt; It being a variant, containing the value of either a vector (&quot=
;list of ints&quot;) or a map (&quot;map of one to another int&quot;), I fi=
nd it just intuitive that one should be able to list initialize it with &qu=
ot;{1, 2, 3}&quot;. However, the constructor consomes the outer brace. I th=
ink the implication here is that the constructor constructs a value which &=
quot;wraps&quot; something. I this case it seems however that this makes th=
ings more complicated to the user, since they have to remember how many bra=
ces to put.=A0<br>

&gt;&gt;<br>
&gt;&gt; What about making an opportunity to mark them as an initializer co=
nstructor?=A0<br>
&gt;&gt;<br>
&gt;&gt; =A0 =A0 struct Variant {<br>
&gt;&gt; =A0 =A0 =A0 continue Variant(std::map&lt;int, int&gt;);<br>
&gt;&gt; =A0 =A0 =A0 continue Variant(std::vector&lt;string&gt;);<br>
&gt;&gt; =A0 =A0 };<br>
&gt;<br>
&gt;<br>
&gt; Somewhat dodging your proposal, I think the following class design wou=
ld fix the problem for the users:<br>
&gt;<br>
&gt; struct Variant<br>
&gt; {<br>
&gt; =A0 =A0 Variant(std::initializer_list&lt;std::pair&lt;int, int&gt;&gt;=
);<br>
&gt; =A0 =A0 Variant(std::initializer_list&lt;int&gt;);<br>
&gt; };<br>
&gt;<br>
&gt; And I think the interface is still (self explanatory) clear enough. Of=
 course, you need a third constructor to tell what the following initializa=
tion means:<br>
&gt;</p>
<p dir=3D"ltr">This is a reasonable nongeneric solution. For classes like o=
ptional or variant, it would need to detect the element type somehow (relyi=
ng on a typedef?).</p>
<p dir=3D"ltr">Anyhow, i will make it one more difficult</p>
<p dir=3D"ltr">=A0=A0=A0 struct optional {<br>
=A0=A0=A0=A0=A0=A0 continue optional(pair &lt;int, int&gt;);<br>
=A0=A0=A0 };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">=A0=A0 optional o {a, b};<br>
=A0 </p>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b15a465409cbd04e4d5d22f--

.

------=_Part_1824_16112929.1377507614079
Content-Type: text/plain; charset=ISO-8859-1

On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Schaub wrote:
>
>
> Anyhow, i will make it one more difficult
>
>     struct optional {
>        continue optional(pair <int, int>);
>     };
>
> What options/workarounds are there to make this valid?
>
>    optional o {a, b};
>
>
A simple converting forwarding constructor should be fine:

template<class T>
struct optional {
  template<class... Args, EnableIf<std::is_constructable<T, Args...>>...>
  optional(Args&&... args) : ...
};

--

---
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_1824_16112929.1377507614079
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Sch=
aub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><p dir=3D"ltr">A=
nyhow, i will make it one more difficult</p>
<p dir=3D"ltr">&nbsp;&nbsp;&nbsp; struct optional {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue optional(pair &lt;int, int&gt=
;);<br>
&nbsp;&nbsp;&nbsp; };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">&nbsp;&nbsp; optional o {a, b};<br>
&nbsp; </p></blockquote><div>A simple converting forwarding constructor sho=
uld be fine:<br><br>template&lt;class T&gt;<br>struct optional {<br>&nbsp; =
template&lt;class... Args, EnableIf&lt;std::is_constructable&lt;T, Args...&=
gt;&gt;...&gt;<br>&nbsp; optional(Args&amp;&amp;... args) : ...<br>}; <br><=
/div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1824_16112929.1377507614079--

.

------=_Part_80_23793446.1377509104744
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo nap=
isa=B3:
>
> On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Schaub wrote:
>>
>>
>> Anyhow, i will make it one more difficult
>>
>>     struct optional {
>>        continue optional(pair <int, int>);
>>     };
>>
>> What options/workarounds are there to make this valid?
>>
>>    optional o {a, b};
>>  =20
>>
> A simple converting forwarding constructor should be fine:
>
> template<class T>
> struct optional {
>   template<class... Args, EnableIf<std::is_constructable<T, Args...>>...>
>   optional(Args&&... args) : ...
> };=20
>

That may not be good enough: such "perfect forwarding constructor" does not=
=20
preserve explicit/non-explicit property, it doesn't forward=20
std::initializer_list, prevents copy-elision optimizations. I guess what=20
Johannes is proposing is the generalisation of "inheriting constructors"=20
for the cases where your type does not inherit from anything. Am I right?=
=20

Regards,
&rzej

--=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_80_23793446.1377509104744
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 U=
TC+2 u=BFytkownik Xeo napisa=B3:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr">On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes S=
chaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br><p dir=3D"ltr">Anyh=
ow, i will make it one more difficult</p>
<p dir=3D"ltr">&nbsp;&nbsp;&nbsp; struct optional {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue optional(pair &lt;int, int&gt=
;);<br>
&nbsp;&nbsp;&nbsp; };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">&nbsp;&nbsp; optional o {a, b};<br>
&nbsp; </p></blockquote><div>A simple converting forwarding constructor sho=
uld be fine:<br><br>template&lt;class T&gt;<br>struct optional {<br>&nbsp; =
template&lt;class... Args, EnableIf&lt;std::is_<wbr>constructable&lt;T, Arg=
s...&gt;&gt;...&gt;<br>&nbsp; optional(Args&amp;&amp;... args) : ...<br>}; =
<br></div></div></blockquote><div><br>That may not be good enough: such "pe=
rfect forwarding constructor" does not preserve explicit/non-explicit prope=
rty, it doesn't forward std::initializer_list, prevents copy-elision optimi=
zations. I guess what Johannes is proposing is the generalisation of "inher=
iting constructors" for the cases where your type does not inherit from any=
thing. Am I right? <br><br>Regards,<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_80_23793446.1377509104744--

.

------=_Part_314_18722291.1377509275234
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu poniedzia=B3ek, 26 sierpnia 2013 10:48:33 UTC+2 u=BFytkownik Johanne=
s=20
Schaub napisa=B3:
>
>
> Am 26.08.2013 09:16 schrieb "Andrzej Krzemie=F1ski" <akrz...@gmail.com<ja=
vascript:>
> >:
> >
> >
> >
> > W dniu poniedzia=B3ek, 26 sierpnia 2013 07:48:50 UTC+2 u=BFytkownik Joh=
annes=20
> Schaub napisa=B3:
> >>
> >> Sometimes I wonder whether one should be able to declare that one=20
> constructor (which probably should not be declared "explicit") should not=
=20
> consume braces
> >>
> >>     struct Variant {
> >>       Variant(std::map<int, int>);
> >>       Variant(std::vector<string>);
> >>     };
> >>
> >>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
> >>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
> >>
> >> It being a variant, containing the value of either a vector ("list of=
=20
> ints") or a map ("map of one to another int"), I find it just intuitive=
=20
> that one should be able to list initialize it with "{1, 2, 3}". However,=
=20
> the constructor consomes the outer brace. I think the implication here is=
=20
> that the constructor constructs a value which "wraps" something. I this=
=20
> case it seems however that this makes things more complicated to the user=
,=20
> since they have to remember how many braces to put.=20
> >>
> >> What about making an opportunity to mark them as an initializer=20
> constructor?=20
> >>
> >>     struct Variant {
> >>       continue Variant(std::map<int, int>);
> >>       continue Variant(std::vector<string>);
> >>     };
> >
> >
> > Somewhat dodging your proposal, I think the following class design woul=
d=20
> fix the problem for the users:
> >
> > struct Variant
> > {
> >     Variant(std::initializer_list<std::pair<int, int>>);
> >     Variant(std::initializer_list<int>);
> > };
> >
> > And I think the interface is still (self explanatory) clear enough. Of=
=20
> course, you need a third constructor to tell what the following=20
> initialization means:
> >
>
> This is a reasonable nongeneric solution. For classes like optional or=20
> variant, it would need to detect the element type somehow (relying on a=
=20
> typedef?).
>
> Anyhow, i will make it one more difficult
>
>     struct optional {
>        continue optional(pair <int, int>);
>     };
>
> What options/workarounds are there to make this valid?
>
>    optional o {a, b};
>

This in fact remained an unresolved problem for std::optional.

--=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_314_18722291.1377509275234
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu poniedzia=B3ek, 26 sierpnia 2013 10:48:33 U=
TC+2 u=BFytkownik Johannes Schaub napisa=B3:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><p dir=3D"ltr"><br>
Am 26.08.2013 09:16 schrieb "Andrzej Krzemie=F1ski" &lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ua2Na5TZDAsJ">akrz...@gmail=
..com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; W dniu poniedzia=B3ek, 26 sierpnia 2013 07:48:50 UTC+2 u=BFytkownik Jo=
hannes Schaub napisa=B3:<br>
&gt;&gt;<br>
&gt;&gt; Sometimes I wonder whether one should be able to declare that one =
constructor (which probably should not be declared "explicit") should not c=
onsume braces<br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; struct Variant {<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; Variant(std::map&lt;int, int&gt;);<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; Variant(std::vector&lt;string&gt;);<br>
&gt;&gt; &nbsp; &nbsp; };<br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-for=
med!<br>
&gt;&gt; &nbsp; &nbsp; Variant v2{1, 2, 3}; // unfortunately, ill-formed!<b=
r>
&gt;&gt;<br>
&gt;&gt; It being a variant, containing the value of either a vector ("list=
 of ints") or a map ("map of one to another int"), I find it just intuitive=
 that one should be able to list initialize it with "{1, 2, 3}". However, t=
he constructor consomes the outer brace. I think the implication here is th=
at the constructor constructs a value which "wraps" something. I this case =
it seems however that this makes things more complicated to the user, since=
 they have to remember how many braces to put.&nbsp;<br>

&gt;&gt;<br>
&gt;&gt; What about making an opportunity to mark them as an initializer co=
nstructor?&nbsp;<br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; struct Variant {<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; continue Variant(std::map&lt;int, int&gt;);<b=
r>
&gt;&gt; &nbsp; &nbsp; &nbsp; continue Variant(std::vector&lt;string&gt;);<=
br>
&gt;&gt; &nbsp; &nbsp; };<br>
&gt;<br>
&gt;<br>
&gt; Somewhat dodging your proposal, I think the following class design wou=
ld fix the problem for the users:<br>
&gt;<br>
&gt; struct Variant<br>
&gt; {<br>
&gt; &nbsp; &nbsp; Variant(std::initializer_list&lt;<wbr>std::pair&lt;int, =
int&gt;&gt;);<br>
&gt; &nbsp; &nbsp; Variant(std::initializer_list&lt;<wbr>int&gt;);<br>
&gt; };<br>
&gt;<br>
&gt; And I think the interface is still (self explanatory) clear enough. Of=
 course, you need a third constructor to tell what the following initializa=
tion means:<br>
&gt;</p>
<p dir=3D"ltr">This is a reasonable nongeneric solution. For classes like o=
ptional or variant, it would need to detect the element type somehow (relyi=
ng on a typedef?).</p>
<p dir=3D"ltr">Anyhow, i will make it one more difficult</p>
<p dir=3D"ltr">&nbsp;&nbsp;&nbsp; struct optional {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue optional(pair &lt;int, int&gt=
;);<br>
&nbsp;&nbsp;&nbsp; };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">&nbsp;&nbsp; optional o {a, b};<br></p></blockquote><div><br=
>This in fact remained an unresolved problem for std::optional.<br></div></=
div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_314_18722291.1377509275234--

.

------=_Part_1667_10341368.1377522441231
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On Monday, August 26, 2013 2:25:04 AM UTC-7, Andrzej Krzemie=F1ski wrote:
>
> W dniu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo=
=20
> napisa=B3:
>>
>> On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Schaub wrote:
>>>
>>>
>>> Anyhow, i will make it one more difficult
>>>
>>>     struct optional {
>>>        continue optional(pair <int, int>);
>>>     };
>>>
>>> What options/workarounds are there to make this valid?
>>>
>>>    optional o {a, b};
>>>  =20
>>>
>> A simple converting forwarding constructor should be fine:
>>
>> template<class T>
>> struct optional {
>>   template<class... Args, EnableIf<std::is_constructable<T, Args...>>...=
>
>>   optional(Args&&... args) : ...
>> };=20
>>
>
> That may not be good enough: such "perfect forwarding constructor" does=
=20
> not preserve explicit/non-explicit property,
>

Considering how much I hate the fact that "explicit" shuts off uniform=20
initialization, I'd consider that an improvement.

it doesn't forward std::initializer_list,
>

Easily achieved with an additional overload:

template<class T>
struct optional {
  template<class... Args, EnableIf<std::is_constructable<T, Args...>>...>
  optional(Args&&... args) : ...

  template<class Arg, EnableIf<std::is_constructable<T, std::
initializer_list<Arg>>>
  optional(std::initializer_list<Arg> arg) : ...
};

prevents copy-elision optimizations.
>

That's an optimization; it doesn't count.

I guess what Johannes is proposing is the generalisation of "inheriting=20
> constructors" for the cases where your type does not inherit from anythin=
g.=20
> Am I right?=20
>
> Regards,
> &rzej
>

--=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_1667_10341368.1377522441231
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 26, 2013 2:25:04 AM UTC-7, Andrzej Krzem=
ie=F1ski 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=
">W dniu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo n=
apisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday=
, August 26, 2013 10:48:33 AM UTC+2, Johannes Schaub wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><br><p dir=3D"ltr">Anyhow, i will make it one more =
difficult</p>
<p dir=3D"ltr">&nbsp;&nbsp;&nbsp; struct optional {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue optional(pair &lt;int, int&gt=
;);<br>
&nbsp;&nbsp;&nbsp; };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">&nbsp;&nbsp; optional o {a, b};<br>
&nbsp; </p></blockquote><div>A simple converting forwarding constructor sho=
uld be fine:<br><br>template&lt;class T&gt;<br>struct optional {<br>&nbsp; =
template&lt;class... Args, EnableIf&lt;std::is_<wbr>constructable&lt;T, Arg=
s...&gt;&gt;...&gt;<br>&nbsp; optional(Args&amp;&amp;... args) : ...<br>}; =
<br></div></div></blockquote><div><br>That may not be good enough: such "pe=
rfect forwarding constructor" does not preserve explicit/non-explicit prope=
rty,</div></div></blockquote><div><br>Considering how much I hate the fact =
that "explicit" shuts off uniform initialization, I'd consider that an impr=
ovement.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>it doesn't forward std::initializer_list,</div></div></blockq=
uote><div><br>Easily achieved with an additional overload:<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> optional </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">EnableIf</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">is_constructable</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=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: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">...&gt;&gt;...&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; opt=
ional</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;...</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> args</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br>&nbsp; </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Arg</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">EnableIf</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">is_constructable</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=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: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">initializer_=
list</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Arg</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt;&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; option=
al</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">initializer_list</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Arg</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> arg</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>prevents copy-elision optimizations.</div></div></blockquote><div><br>=
That's an optimization; it doesn't count.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div> I guess what Johannes is pr=
oposing is the generalisation of "inheriting constructors" for the cases wh=
ere your type does not inherit from anything. Am I right? <br><br>Regards,<=
br>&amp;rzej<br></div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1667_10341368.1377522441231--

.

------=_Part_574_13728956.1377536734699
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Monday, August 26, 2013 3:07:21 PM UTC+2, Nicol Bolas wrote:
>
> On Monday, August 26, 2013 2:25:04 AM UTC-7, Andrzej Krzemie=F1ski wrote:
>>
>> W dniu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo=
=20
>> napisa=B3:
>>>
>>> On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Schaub wrote:
>>>>
>>>>
>>>> Anyhow, i will make it one more difficult
>>>>
>>>>     struct optional {
>>>>        continue optional(pair <int, int>);
>>>>     };
>>>>
>>>> What options/workarounds are there to make this valid?
>>>>
>>>>    optional o {a, b};
>>>>  =20
>>>>
>>> A simple converting forwarding constructor should be fine:
>>>
>>> template<class T>
>>> struct optional {
>>>   template<class... Args, EnableIf<std::is_constructable<T, Args...>>..=
..>
>>>   optional(Args&&... args) : ...
>>> };=20
>>>
>>
>> That may not be good enough: such "perfect forwarding constructor" does=
=20
>> not preserve explicit/non-explicit property,
>>
>
> Considering how much I hate the fact that "explicit" shuts off uniform=20
> initialization, I'd consider that an improvement.
>

I think that "explicit" is a good thing and that the unfortunate failure=20
with it not working well with std::tuple isn't "explicit"'s fault.


> it doesn't forward std::initializer_list,
>>
>
> Easily achieved with an additional overload:
>
> template<class T>
> struct optional {
>   template<class... Args, EnableIf<std::is_constructable<T, Args...>>...>
>   optional(Args&&... args) : ...
>
>   template<class Arg, EnableIf<std::is_constructable<T, std::
> initializer_list<Arg>>>
>   optional(std::initializer_list<Arg> arg) : ...
> };
>
>>
>>
I suppose what was meant was "initializer lists" as opposed to=20
"std::initializer_list". For instance, try making this work *generically*

    struct optional {
       continue optional(pair <std::vector<int>, int>);
    };

    optional o{{1, 2, 3}, 4};

The inner "{ ... }" won't deduce against a template parameter. It will=20
become arbitrarily complicated.=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_574_13728956.1377536734699
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, August 26, 2013 3:07:21 PM UTC+2, Nicol=
 Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On Monday, August 26, 2013 2:25:04 AM UTC-7, Andrzej Krzemie=F1ski wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">W dniu poniedzia=B3e=
k, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo napisa=B3:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 26, 2013 10:4=
8:33 AM UTC+2, Johannes Schaub wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><br><p dir=3D"ltr">Anyhow, i will make it one more difficult</p>
<p dir=3D"ltr">&nbsp;&nbsp;&nbsp; struct optional {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue optional(pair &lt;int, int&gt=
;);<br>
&nbsp;&nbsp;&nbsp; };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">&nbsp;&nbsp; optional o {a, b};<br>
&nbsp; </p></blockquote><div>A simple converting forwarding constructor sho=
uld be fine:<br><br>template&lt;class T&gt;<br>struct optional {<br>&nbsp; =
template&lt;class... Args, EnableIf&lt;std::is_<wbr>constructable&lt;T, Arg=
s...&gt;&gt;...&gt;<br>&nbsp; optional(Args&amp;&amp;... args) : ...<br>}; =
<br></div></div></blockquote><div><br>That may not be good enough: such "pe=
rfect forwarding constructor" does not preserve explicit/non-explicit prope=
rty,</div></div></blockquote><div><br>Considering how much I hate the fact =
that "explicit" shuts off uniform initialization, I'd consider that an impr=
ovement.<br></div></div></blockquote><div><br></div><div>I think that "expl=
icit" is a good thing and that the unfortunate failure with it not working =
well with std::tuple isn't "explicit"'s fault.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><block=
quote 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>it doesn't forward =
std::initializer_list,</div></div></blockquote><div><br>Easily achieved wit=
h an additional overload:<br><br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;wor=
d-wrap:break-word"><code><div><span style=3D"color:#008">template</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><=
span style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><s=
pan style=3D"color:#000"><br></span><span style=3D"color:#008">struct</span=
><span style=3D"color:#000"> optional </span><span style=3D"color:#660">{</=
span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008=
">template</span><span style=3D"color:#660">&lt;</span><span style=3D"color=
:#008">class</span><span style=3D"color:#660">...</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">Args</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606"=
>EnableIf</span><span style=3D"color:#660">&lt;</span><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">is_constructable</span><span style=3D"color:#660"><wbr>&lt;</span><span=
 style=3D"color:#000">T</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#606">Args</span><span style=
=3D"color:#660">...&gt;&gt;...&gt;</span><span style=3D"color:#000"><br>&nb=
sp; optional</span><span style=3D"color:#660">(</span><span style=3D"color:=
#606">Args</span><span style=3D"color:#660">&amp;&amp;...</span><span style=
=3D"color:#000"> args</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">:</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">...</span><span style=3D"colo=
r:#000"><br><br>&nbsp; </span><span style=3D"color:#008">template</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#008">class</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">Arg</span><spa=
n style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">EnableIf</span><span style=3D"color:#660">&lt;</span><spa=
n style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span =
style=3D"color:#000">is_constructable</span><span style=3D"color:#660"><wbr=
>&lt;</span><span style=3D"color:#000">T</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::<=
/span><span style=3D"color:#000">initializer_list</span><span style=3D"colo=
r:#660">&lt;</span><span style=3D"color:#606">Arg</span><span style=3D"colo=
r:#660">&gt;&gt;&gt;</span><span style=3D"color:#000"><br>&nbsp; optional</=
span><span style=3D"color:#660">(</span><span style=3D"color:#000">std</spa=
n><span style=3D"color:#660">::</span><span style=3D"color:#000">initialize=
r_list</span><span style=3D"color:#660"><wbr>&lt;</span><span style=3D"colo=
r:#606">Arg</span><span style=3D"color:#660">&gt;</span><span style=3D"colo=
r:#000"> arg</span><span style=3D"color:#660">)</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">:</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">...</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#660">};</span></div></code></div></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div></div></=
blockquote></div></blockquote><div><br></div><div>I suppose what was meant =
was "initializer lists" as opposed to "std::initializer_list". For instance=
, try making this work *generically*</div><div><br></div><div>&nbsp; &nbsp;=
 struct optional {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue optiona=
l(pair &lt;std::vector&lt;int&gt;, int&gt;);<br>&nbsp;&nbsp;&nbsp; };<br></=
div><div><br></div><div>&nbsp; &nbsp; optional o{{1, 2, 3}, 4};</div><div><=
br></div><div>The inner "{ ... }" won't deduce against a template parameter=
.. It will become arbitrarily complicated.&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_574_13728956.1377536734699--

.

--089e0139ff7695337e04e4de2bb5
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

On 26 August 2013 20:05, Johannes Schaub <schaub.johannes@googlemail.com>wr=
ote:

>
>
> On Monday, August 26, 2013 3:07:21 PM UTC+2, Nicol Bolas wrote:
>>
>> On Monday, August 26, 2013 2:25:04 AM UTC-7, Andrzej Krzemie=F1ski wrote=
:
>>>
>>> W dniu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo
>>> napisa=B3:
>>>>
>>>> On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Schaub wrote:
>>>>>
>>>>>
>>>>> Anyhow, i will make it one more difficult
>>>>>
>>>>>     struct optional {
>>>>>        continue optional(pair <int, int>);
>>>>>     };
>>>>>
>>>>> What options/workarounds are there to make this valid?
>>>>>
>>>>>    optional o {a, b};
>>>>>
>>>>>
>>>> A simple converting forwarding constructor should be fine:
>>>>
>>>> template<class T>
>>>> struct optional {
>>>>   template<class... Args, EnableIf<std::is_**constructable<T,
>>>> Args...>>...>
>>>>   optional(Args&&... args) : ...
>>>> };
>>>>
>>>
>>> That may not be good enough: such "perfect forwarding constructor" does
>>> not preserve explicit/non-explicit property,
>>>
>>
>> Considering how much I hate the fact that "explicit" shuts off uniform
>> initialization, I'd consider that an improvement.
>>
>
> I think that "explicit" is a good thing and that the unfortunate failure
> with it not working well with std::tuple isn't "explicit"'s fault.
>
>
>> it doesn't forward std::initializer_list,
>>>
>>
>> Easily achieved with an additional overload:
>>
>> template<class T>
>> struct optional {
>>   template<class... Args, EnableIf<std::is_constructable**<T, Args
>> ...>>...>
>>   optional(Args&&... args) : ...
>>
>>   template<class Arg, EnableIf<std::is_constructable**<T, std::
>> initializer_list<Arg>>>
>>   optional(std::initializer_list**<Arg> arg) : ...
>> };
>>
>>>
>>>
> I suppose what was meant was "initializer lists" as opposed to
> "std::initializer_list". For instance, try making this work *generically*
>
>     struct optional {
>        continue optional(pair <std::vector<int>, int>);
>     };
>
>     optional o{{1, 2, 3}, 4};
>
> The inner "{ ... }" won't deduce against a template parameter. It will
> become arbitrarily complicated.
>
>
>
>
FWIW, I don't expect an optional<pair<int, int>> to be constructible with
{1,1} rather than {{1,1}}, and I
have no interest in working to get it to accept the former form.

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

--089e0139ff7695337e04e4de2bb5
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 August 2013 20:05, Johannes Schaub <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.joha=
nnes@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br><br>O=
n Monday, August 26, 2013 3:07:21 PM UTC+2, Nicol Bolas wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr">On Monday, August 26, 2013 2:25:04 AM UTC-7, Andrzej Krzem=
ie=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">W d=
niu poniedzia=B3ek, 26 sierpnia 2013 11:00:14 UTC+2 u=BFytkownik Xeo napisa=
=B3:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On Monday, August 26, 2013 10:48:33 AM UTC+2, Johannes Sch=
aub wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><br><p dir=3D"ltr">Anyhow=
, i will make it one more difficult</p>

<p dir=3D"ltr">=A0=A0=A0 struct optional {<br>
=A0=A0=A0=A0=A0=A0 continue optional(pair &lt;int, int&gt;);<br>
=A0=A0=A0 };</p>
<p dir=3D"ltr">What options/workarounds are there to make this valid?</p>
<p dir=3D"ltr">=A0=A0 optional o {a, b};<br>
=A0 </p></blockquote><div>A simple converting forwarding constructor should=
 be fine:<br><br>template&lt;class T&gt;<br>struct optional {<br>=A0 templa=
te&lt;class... Args, EnableIf&lt;std::is_<u></u>constructable&lt;T, Args...=
&gt;&gt;...&gt;<br>
=A0 optional(Args&amp;&amp;... args) : ...<br>}; <br></div></div></blockquo=
te><div><br>That may not be good enough: such &quot;perfect forwarding cons=
tructor&quot; does not preserve explicit/non-explicit property,</div></div>
</blockquote><div><br>Considering how much I hate the fact that &quot;expli=
cit&quot; shuts off uniform initialization, I&#39;d consider that an improv=
ement.<br></div></div></blockquote><div><br></div></div><div>I think that &=
quot;explicit&quot; is a good thing and that the unfortunate failure with i=
t not working well with std::tuple isn&#39;t &quot;explicit&quot;&#39;s fau=
lt.</div>
<div class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>it doesn&#39;t forward std::initializer_list,</div></=
div></blockquote><div><br>Easily achieved with an additional overload:<br><=
br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px;word-wrap:break-word">
<code><div><span style=3D"color:#008">template</span><span style=3D"color:#=
660">&lt;</span><span style=3D"color:#008">class</span><span style> T</span=
><span style=3D"color:#660">&gt;</span><span style><br></span><span style=
=3D"color:#008">struct</span><span style> optional </span><span style=3D"co=
lor:#660">{</span><span style><br>
=A0 </span><span style=3D"color:#008">template</span><span style=3D"color:#=
660">&lt;</span><span style=3D"color:#008">class</span><span style=3D"color=
:#660">...</span><span style> </span><span style=3D"color:#606">Args</span>=
<span style=3D"color:#660">,</span><span style> </span><span style=3D"color=
:#606">EnableIf</span><span style=3D"color:#660">&lt;</span><span style>std=
</span><span style=3D"color:#660">::</span><span style>is_constructable</sp=
an><span style=3D"color:#660"><u></u>&lt;</span><span style>T</span><span s=
tyle=3D"color:#660">,</span><span style> </span><span style=3D"color:#606">=
Args</span><span style=3D"color:#660">...&gt;&gt;...&gt;</span><span style>=
<br>
=A0 optional</span><span style=3D"color:#660">(</span><span style=3D"color:=
#606">Args</span><span style=3D"color:#660">&amp;&amp;...</span><span style=
> args</span><span style=3D"color:#660">)</span><span style> </span><span s=
tyle=3D"color:#660">:</span><span style> </span><span style=3D"color:#660">=
....</span><span style><br>
<br>=A0 </span><span style=3D"color:#008">template</span><span style=3D"col=
or:#660">&lt;</span><span style=3D"color:#008">class</span><span style> </s=
pan><span style=3D"color:#606">Arg</span><span style=3D"color:#660">,</span=
><span style> </span><span style=3D"color:#606">EnableIf</span><span style=
=3D"color:#660">&lt;</span><span style>std</span><span style=3D"color:#660"=
>::</span><span style>is_constructable</span><span style=3D"color:#660"><u>=
</u>&lt;</span><span style>T</span><span style=3D"color:#660">,</span><span=
 style> std</span><span style=3D"color:#660">::</span><span style>initializ=
er_list</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#6=
06">Arg</span><span style=3D"color:#660">&gt;&gt;&gt;</span><span style><br=
>
=A0 optional</span><span style=3D"color:#660">(</span><span style>std</span=
><span style=3D"color:#660">::</span><span style>initializer_list</span><sp=
an style=3D"color:#660"><u></u>&lt;</span><span style=3D"color:#606">Arg</s=
pan><span style=3D"color:#660">&gt;</span><span style> arg</span><span styl=
e=3D"color:#660">)</span><span style> </span><span style=3D"color:#660">:</=
span><span style> </span><span style=3D"color:#660">...</span><span style><=
br>
</span><span style=3D"color:#660">};</span></div></code></div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div></div></bl=
ockquote>
</div></blockquote><div><br></div></div><div>I suppose what was meant was &=
quot;initializer lists&quot; as opposed to &quot;std::initializer_list&quot=
;. For instance, try making this work *generically*</div><div><br></div>
<div>=A0 =A0 struct optional {<br>=A0=A0=A0=A0=A0=A0 continue optional(pair=
 &lt;std::vector&lt;int&gt;, int&gt;);<br>=A0=A0=A0 };<br></div><div><br></=
div><div>=A0 =A0 optional o{{1, 2, 3}, 4};</div><div><br></div><div>The inn=
er &quot;{ ... }&quot; won&#39;t deduce against a template parameter. It wi=
ll become arbitrarily complicated.=A0</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>FWIW, I don&#39;t expe=
ct an optional&lt;pair&lt;int, int&gt;&gt; to be constructible with {1,1} r=
ather than {{1,1}}, and I<br>have no interest in working to get it to accep=
t the former form.<br>
</div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0139ff7695337e04e4de2bb5--

.

------=_Part_7_33127630.1377560474067
Content-Type: text/plain; charset=ISO-8859-1



On Monday, August 26, 2013 1:48:50 PM UTC+8, Johannes Schaub wrote:
>
> Sometimes I wonder whether one should be able to declare that one
> constructor (which probably should not be declared "explicit") should not
> consume braces
>
>     struct Variant {
>       Variant(std::map<int, int>);
>       Variant(std::vector<string>);
>     };
>
>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
>
> It being a variant, containing the value of either a vector ("list of
> ints") or a map ("map of one to another int"), I find it just intuitive
> that one should be able to list initialize it with "{1, 2, 3}". However,
> the constructor consomes the outer brace. I think the implication here is
> that the constructor constructs a value which "wraps" something. I this
> case it seems however that this makes things more complicated to the user,
> since they have to remember how many braces to put.
>

The task at hand is to delegate construction to one member or another,
disallowing ambiguity. The braced-init-list doesn't seem essential here;
it's not a std::initializer_list and we could have members, generalizing,
being anything including aggregates. You just chose an example using
containers, but a Variant generally doesn't require such.

Inheriting constructors from a member rather than a base class is generally
useful for adaptor patterns: Private inheritance may be too messy, yet an
adaptor also wants to hide the fact that it is an intermediary. The
existing inheriting constructor semantics seem sufficient to me, but
aggregate support would be nice. In generic template usage you wouldn't
generally be able to detect and prevent a collision. I guess you don't
really perceive that to be a problem.

--

---
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_7_33127630.1377560474067
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, August 26, 2013 1:48:50 PM UTC+8, Johan=
nes Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Sometimes I wonder whether one should be able to declare that one const=
ructor (which probably should not be declared "explicit") should not consum=
e braces<div><br></div><div>&nbsp; &nbsp; struct Variant {</div><div>&nbsp;=
 &nbsp; &nbsp; Variant(std::map&lt;int, int&gt;);</div><div>&nbsp; &nbsp; &=
nbsp; Variant(std::vector&lt;string&gt;);</div><div>&nbsp; &nbsp; };</div><=
div><br></div><div>&nbsp; &nbsp; Variant v{{1, 2}, {3, 4}}; // unfortunatel=
y, ill-formed!</div><div>&nbsp; &nbsp; Variant v2{1, 2, 3}; // unfortunatel=
y, ill-formed!</div><div><br></div><div>It being a variant, containing the =
value of either a vector ("list of ints") or a map ("map of one to another =
int"), I find it just intuitive that one should be able to list initialize =
it with "{1, 2, 3}". However, the constructor consomes the outer brace. I t=
hink the implication here is that the constructor constructs a value which =
"wraps" something. I this case it seems however that this makes things more=
 complicated to the user, since they have to remember how many braces to pu=
t.&nbsp;</div></div></blockquote><div><br>The task at hand is to delegate c=
onstruction to one member or another, disallowing ambiguity. The braced-ini=
t-list doesn't seem essential here; it's not a std::initializer_list and we=
 could have members, generalizing, being anything including aggregates. You=
 just chose an example using containers, but a Variant generally doesn't re=
quire such.<br><br>Inheriting constructors from a member rather than a base=
 class is generally useful for adaptor patterns: Private inheritance may be=
 too messy, yet an adaptor also wants to hide the fact that it is an interm=
ediary. The existing inheriting constructor semantics seem sufficient to me=
, but aggregate support would be nice. In generic template usage you wouldn=
't generally be able to detect and prevent a collision. I guess you don't r=
eally perceive that to be a problem.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_7_33127630.1377560474067--

.

------=_Part_3_31535406.1377560994159
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, August 27, 2013 2:46:11 AM UTC+8, Ville Voutilainen wrote:
>
>
> FWIW, I don't expect an optional<pair<int, int>> to be constructible with
> {1,1} rather than {{1,1}}, and I
> have no interest in working to get it to accept the former form.
>

Specifically, default construction would become very vague. There would
have to be a special empty_optional value to be used as a disambiguating
initializer. Yuck.

--

---
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_3_31535406.1377560994159
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 2:46:11 AM UTC+8, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div><div class=3D"gmail_quote"><div>FWIW, I don't expect an o=
ptional&lt;pair&lt;int, int&gt;&gt; to be constructible with {1,1} rather t=
han {{1,1}}, and I<br>have no interest in working to get it to accept the f=
ormer form.<br></div></div></div></div></blockquote><div><br>Specifically, =
default construction would become very vague. There would have to be a spec=
ial empty_optional value to be used as a disambiguating initializer. Yuck. =
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3_31535406.1377560994159--

.

--047d7b5dbe7a419a6d04e4e2c4b9
Content-Type: text/plain; charset=ISO-8859-1

On 27 August 2013 02:49, David Krauss <potswa@gmail.com> wrote:

> On Tuesday, August 27, 2013 2:46:11 AM UTC+8, Ville Voutilainen wrote:
>>
>>
>> FWIW, I don't expect an optional<pair<int, int>> to be constructible with
>> {1,1} rather than {{1,1}}, and I
>> have no interest in working to get it to accept the former form.
>>
>
> Specifically, default construction would become very vague. There would
> have to be a special empty_optional value to be used as a disambiguating
> initializer. Yuck.
>
>
>
>
Well, whether it's "yuck" or not, we already have it, it's called nullopt,
see [optional.nullopt].

--

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

--047d7b5dbe7a419a6d04e4e2c4b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 August 2013 02:49, David Krauss <span dir=3D"ltr">&lt;<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"im">On Tuesday, August 27, 2013 2:46:11 AM UTC+8, Ville Voutilainen w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br><div><div class=3D"gmail_quote"><div>FWIW, I don&#39;t=
 expect an optional&lt;pair&lt;int, int&gt;&gt; to be constructible with {1=
,1} rather than {{1,1}}, and I<br>have no interest in working to get it to =
accept the former form.<br>
</div></div></div></div></blockquote></div><div><br>Specifically, default c=
onstruction would become very vague. There would have to be a special empty=
_optional value to be used as a disambiguating initializer. Yuck. <br></div=
>
</div><div class=3D""><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>Well, whether it&#39;s=
 &quot;yuck&quot; or not, we already have it, it&#39;s called nullopt, see =
[optional.nullopt].<br>=A0<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b5dbe7a419a6d04e4e2c4b9--

.

------=_Part_57_5024674.1377565912555
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, August 27, 2013 8:15:13 AM UTC+8, Ville Voutilainen wrote:
>
>
> On 27 August 2013 02:49, David Krauss <pot...@gmail.com <javascript:>>wrote:
>
>> On Tuesday, August 27, 2013 2:46:11 AM UTC+8, Ville Voutilainen wrote:
>>>
>>>
>>> FWIW, I don't expect an optional<pair<int, int>> to be constructible
>>> with {1,1} rather than {{1,1}}, and I
>>> have no interest in working to get it to accept the former form.
>>>
>>
>> Specifically, default construction would become very vague. There would
>> have to be a special empty_optional value to be used as a disambiguating
>> initializer. Yuck.
>>
>
> Well, whether it's "yuck" or not, we already have it, it's called nullopt,
> see [optional.nullopt].
>

Thanks for the info. But reviewing the documentation and Boost Optional,
that's only there to help imitate a variant interface. It will help concept
support. It doesn't affect default initialization semantics or ever require
use as far as I know; that's really the yuck part.

--

---
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_57_5024674.1377565912555
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 8:15:13 AM UTC+8, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div><div class=3D"gmail_quote">On 27 August 2013 02:49, David=
 Krauss <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"vexmlH77DZgJ">pot...@gmail.com</a>&gt;</span> wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>On =
Tuesday, August 27, 2013 2:46:11 AM UTC+8, Ville Voutilainen wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br><div><div class=3D"gmail_quote"><div>FWIW, I don't exp=
ect an optional&lt;pair&lt;int, int&gt;&gt; to be constructible with {1,1} =
rather than {{1,1}}, and I<br>have no interest in working to get it to acce=
pt the former form.<br>
</div></div></div></div></blockquote></div><div><br>Specifically, default c=
onstruction would become very vague. There would have to be a special empty=
_optional value to be used as a disambiguating initializer. Yuck. <br></div=
>
</div></blockquote><div><br></div><div>Well, whether it's "yuck" or not, we=
 already have it, it's called nullopt, see [optional.nullopt].<br></div></d=
iv></div></div></blockquote><div><br>Thanks for the info. But reviewing the=
 documentation and Boost Optional, that's only there to help imitate a vari=
ant interface. It will help concept support. It doesn't affect default init=
ialization semantics or ever require use as far as I know; that's really th=
e yuck part.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_57_5024674.1377565912555--

.

------=_Part_23_8709315.1377590527290
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 27 sierpnia 2013 01:41:14 UTC+2 u=BFytkownik David Krauss=20
napisa=B3:
>
>
>
> On Monday, August 26, 2013 1:48:50 PM UTC+8, Johannes Schaub wrote:
>>
>> Sometimes I wonder whether one should be able to declare that one=20
>> constructor (which probably should not be declared "explicit") should no=
t=20
>> consume braces
>>
>>     struct Variant {
>>       Variant(std::map<int, int>);
>>       Variant(std::vector<string>);
>>     };
>>
>>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
>>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
>>
>> It being a variant, containing the value of either a vector ("list of=20
>> ints") or a map ("map of one to another int"), I find it just intuitive=
=20
>> that one should be able to list initialize it with "{1, 2, 3}". However,=
=20
>> the constructor consomes the outer brace. I think the implication here i=
s=20
>> that the constructor constructs a value which "wraps" something. I this=
=20
>> case it seems however that this makes things more complicated to the use=
r,=20
>> since they have to remember how many braces to put.=20
>>
>
> The task at hand is to delegate construction to one member or another,=20
> disallowing ambiguity. The braced-init-list doesn't seem essential here;=
=20
> it's not a std::initializer_list and we could have members, generalizing,=
=20
> being anything including aggregates. You just chose an example using=20
> containers, but a Variant generally doesn't require such.
>
> Inheriting constructors from a member rather than a base class is=20
> generally useful for adaptor patterns: Private inheritance may be too=20
> messy, yet an adaptor also wants to hide the fact that it is an=20
> intermediary. The existing inheriting constructor semantics seem sufficie=
nt=20
> to me, but aggregate support would be nice. In generic template usage you=
=20
> wouldn't generally be able to detect and prevent a collision. I guess you=
=20
> don't really perceive that to be a problem.
>

The case of std::optional showed that sometimes you want to "inherit"=20
constructors from something that is neither a base class nor a member=20
sub-object. The implementation of optional<T> does not have a member T. It=
=20
only has enough raw storage to contain a T. But we still wanted to=20
"inherit" T's constructors.

For the record: I do not intend to propose any such addition to=20
std::optional; I am just sharing my experience.

Regards,
&rzej

--=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_23_8709315.1377590527290
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu wtorek, 27 sierpnia 2013 01:41:14 UTC+2 u=
=BFytkownik David Krauss napisa=B3:<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"><br><br>On Monday, August 26, 2013 1:48:50 PM UTC+8,=
 Johannes Schaub 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">Sometimes I wonder whether one should be able to declare that one cons=
tructor (which probably should not be declared "explicit") should not consu=
me braces<div><br></div><div>&nbsp; &nbsp; struct Variant {</div><div>&nbsp=
; &nbsp; &nbsp; Variant(std::map&lt;int, int&gt;);</div><div>&nbsp; &nbsp; =
&nbsp; Variant(std::vector&lt;string&gt;);</div><div>&nbsp; &nbsp; };</div>=
<div><br></div><div>&nbsp; &nbsp; Variant v{{1, 2}, {3, 4}}; // unfortunate=
ly, ill-formed!</div><div>&nbsp; &nbsp; Variant v2{1, 2, 3}; // unfortunate=
ly, ill-formed!</div><div><br></div><div>It being a variant, containing the=
 value of either a vector ("list of ints") or a map ("map of one to another=
 int"), I find it just intuitive that one should be able to list initialize=
 it with "{1, 2, 3}". However, the constructor consomes the outer brace. I =
think the implication here is that the constructor constructs a value which=
 "wraps" something. I this case it seems however that this makes things mor=
e complicated to the user, since they have to remember how many braces to p=
ut.&nbsp;</div></div></blockquote><div><br>The task at hand is to delegate =
construction to one member or another, disallowing ambiguity. The braced-in=
it-list doesn't seem essential here; it's not a std::initializer_list and w=
e could have members, generalizing, being anything including aggregates. Yo=
u just chose an example using containers, but a Variant generally doesn't r=
equire such.<br><br>Inheriting constructors from a member rather than a bas=
e class is generally useful for adaptor patterns: Private inheritance may b=
e too messy, yet an adaptor also wants to hide the fact that it is an inter=
mediary. The existing inheriting constructor semantics seem sufficient to m=
e, but aggregate support would be nice. In generic template usage you would=
n't generally be able to detect and prevent a collision. I guess you don't =
really perceive that to be a problem.<br></div></div></blockquote><div><br>=
The case of std::optional showed that sometimes you want to "inherit" const=
ructors from something that is neither a base class nor a member sub-object=
.. The implementation of optional&lt;T&gt; does not have a member T. It only=
 has enough raw storage to contain a T. But we still wanted to "inherit" T'=
s constructors.<br><br>For the record: I do not intend to propose any such =
addition to std::optional; I am just sharing my experience.<br><br>Regards,=
<br>&amp;rzej<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_23_8709315.1377590527290--

.

--e89a8ffbad63005ecc04e4e980f4
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Am 27.08.2013 10:02 schrieb "Andrzej Krzemie=F1ski" <akrzemi1@gmail.com>:
>
>
>
> W dniu wtorek, 27 sierpnia 2013 01:41:14 UTC+2 u=BFytkownik David Krauss
napisa=B3:
>>
>>
>>
>> On Monday, August 26, 2013 1:48:50 PM UTC+8, Johannes Schaub wrote:
>>>
>>> Sometimes I wonder whether one should be able to declare that one
constructor (which probably should not be declared "explicit") should not
consume braces
>>>
>>>     struct Variant {
>>>       Variant(std::map<int, int>);
>>>       Variant(std::vector<string>);
>>>     };
>>>
>>>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
>>>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
>>>
>>> It being a variant, containing the value of either a vector ("list of
ints") or a map ("map of one to another int"), I find it just intuitive
that one should be able to list initialize it with "{1, 2, 3}". However,
the constructor consomes the outer brace. I think the implication here is
that the constructor constructs a value which "wraps" something. I this
case it seems however that this makes things more complicated to the user,
since they have to remember how many braces to put.
>>
>>
>> The task at hand is to delegate construction to one member or another,
disallowing ambiguity. The braced-init-list doesn't seem essential here;
it's not a std::initializer_list and we could have members, generalizing,
being anything including aggregates. You just chose an example using
containers, but a Variant generally doesn't require such.
>>
>> Inheriting constructors from a member rather than a base class is
generally useful for adaptor patterns: Private inheritance may be too
messy, yet an adaptor also wants to hide the fact that it is an
intermediary. The existing inheriting constructor semantics seem sufficient
to me, but aggregate support would be nice. In generic template usage you
wouldn't generally be able to detect and prevent a collision. I guess you
don't really perceive that to be a problem.
>
>
> The case of std::optional showed that sometimes you want to "inherit"
constructors from something that is neither a base class nor a member
sub-object. The implementation of optional<T> does not have a member T. It
only has enough raw storage to contain a T. But we still wanted to
"inherit" T's constructors.
>
> For the record: I do not intend to propose any such addition to
std::optional; I am just sharing my experience.
>

Neither do i intend to propose such a thing. I just needed a code example.

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

--e89a8ffbad63005ecc04e4e980f4
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Am 27.08.2013 10:02 schrieb &quot;Andrzej Krzemie=F1ski&quot; &lt;<a href=
=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; W dniu wtorek, 27 sierpnia 2013 01:41:14 UTC+2 u=BFytkownik David Krau=
ss napisa=B3:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Monday, August 26, 2013 1:48:50 PM UTC+8, Johannes Schaub wrote=
:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Sometimes I wonder whether one should be able to declare that =
one constructor (which probably should not be declared &quot;explicit&quot;=
) should not consume braces<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 struct Variant {<br>
&gt;&gt;&gt; =A0 =A0 =A0 Variant(std::map&lt;int, int&gt;);<br>
&gt;&gt;&gt; =A0 =A0 =A0 Variant(std::vector&lt;string&gt;);<br>
&gt;&gt;&gt; =A0 =A0 };<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =A0 =A0 Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-forme=
d!<br>
&gt;&gt;&gt; =A0 =A0 Variant v2{1, 2, 3}; // unfortunately, ill-formed!<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It being a variant, containing the value of either a vector (&=
quot;list of ints&quot;) or a map (&quot;map of one to another int&quot;), =
I find it just intuitive that one should be able to list initialize it with=
 &quot;{1, 2, 3}&quot;. However, the constructor consomes the outer brace. =
I think the implication here is that the constructor constructs a value whi=
ch &quot;wraps&quot; something. I this case it seems however that this make=
s things more complicated to the user, since they have to remember how many=
 braces to put.=A0<br>

&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The task at hand is to delegate construction to one member or anot=
her, disallowing ambiguity. The braced-init-list doesn&#39;t seem essential=
 here; it&#39;s not a std::initializer_list and we could have members, gene=
ralizing, being anything including aggregates. You just chose an example us=
ing containers, but a Variant generally doesn&#39;t require such.<br>

&gt;&gt;<br>
&gt;&gt; Inheriting constructors from a member rather than a base class is =
generally useful for adaptor patterns: Private inheritance may be too messy=
, yet an adaptor also wants to hide the fact that it is an intermediary. Th=
e existing inheriting constructor semantics seem sufficient to me, but aggr=
egate support would be nice. In generic template usage you wouldn&#39;t gen=
erally be able to detect and prevent a collision. I guess you don&#39;t rea=
lly perceive that to be a problem.<br>

&gt;<br>
&gt;<br>
&gt; The case of std::optional showed that sometimes you want to &quot;inhe=
rit&quot; constructors from something that is neither a base class nor a me=
mber sub-object. The implementation of optional&lt;T&gt; does not have a me=
mber T. It only has enough raw storage to contain a T. But we still wanted =
to &quot;inherit&quot; T&#39;s constructors.<br>

&gt;<br>
&gt; For the record: I do not intend to propose any such addition to std::o=
ptional; I am just sharing my experience.<br>
&gt;</p>
<p dir=3D"ltr">Neither do i intend to propose such a thing. I just needed a=
 code example.<br>
</p>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--e89a8ffbad63005ecc04e4e980f4--

.

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

On Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrzej Krzemie=C5=84ski wrot=
e:

The case of std::optional showed that sometimes you want to "inherit"=20
> constructors from something that is neither a base class nor a member=20
> sub-object. The implementation of optional<T> does not have a member T. I=
t=20
> only has enough raw storage to contain a T. But we still wanted to=20
> "inherit" T's constructors.
>
> For the record: I do not intend to propose any such addition to=20
> std::optional; I am just sharing my experience.
>

Besides going so far as a real, specific proposal, do you currently feel it=
=20
would be a good thing?

I attempted a comprehensive analysis of forwarding arguments to object=20
initialization for LWG DR 2089<http://www.open-std.org/jtc1/sc22/wg21/docs/=
lwg-active.html#2089>.=20
The upshot is that even after using perfect forwarding, as long as=20
std::is_constructible works, you can almost always provide a way to do the=
=20
right thing, and that way is usually the intuitive one. I suggest=20
implementing such behavior for std::allocator::construct.

Since it's more generally applicable outside standard containers, maybe I=
=20
should write up a proper proposal paper.

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

<div dir=3D"ltr">On Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrzej Krze=
mie=C5=84ski wrote:<br><br><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">The case of std::optional showed that sometimes you want to "=
inherit" constructors from something that is neither a base class nor a mem=
ber sub-object. The implementation of optional&lt;T&gt; does not have a mem=
ber T. It only has enough raw storage to contain a T. But we still wanted t=
o "inherit" T's constructors.<br><div><br>For the record: I do not intend t=
o propose any such addition to std::optional; I am just sharing my experien=
ce.</div></div></blockquote><div><br>Besides going so far as a real, specif=
ic proposal, do you currently feel it would be a good thing?<br><br>I attem=
pted a comprehensive analysis of forwarding arguments to object initializat=
ion for <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.h=
tml#2089">LWG DR 2089</a>. The upshot is that even after using perfect forw=
arding, as long as std::is_constructible works, you can almost always provi=
de a way to do the right thing, and that way is usually the intuitive one. =
I suggest implementing such behavior for std::allocator::construct.<br><br>=
Since it's more generally applicable outside standard containers, maybe I s=
hould write up a proper proposal paper.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_385_26936223.1377592978256--

.

--047d7b6d966ec9366804e4eeb041
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Am 27.08.2013 10:17 schrieb "Johannes Schaub" <
schaub.johannes@googlemail.com>:
>
>
> Am 27.08.2013 10:02 schrieb "Andrzej Krzemie=F1ski" <akrzemi1@gmail.com>:
>
> >
> >
> >
> > W dniu wtorek, 27 sierpnia 2013 01:41:14 UTC+2 u=BFytkownik David Kraus=
s
napisa=B3:
> >>
> >>
> >>
> >> On Monday, August 26, 2013 1:48:50 PM UTC+8, Johannes Schaub wrote:
> >>>
> >>> Sometimes I wonder whether one should be able to declare that one
constructor (which probably should not be declared "explicit") should not
consume braces
> >>>
> >>>     struct Variant {
> >>>       Variant(std::map<int, int>);
> >>>       Variant(std::vector<string>);
> >>>     };
> >>>
> >>>     Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-formed!
> >>>     Variant v2{1, 2, 3}; // unfortunately, ill-formed!
> >>>
> >>> It being a variant, containing the value of either a vector ("list of
ints") or a map ("map of one to another int"), I find it just intuitive
that one should be able to list initialize it with "{1, 2, 3}". However,
the constructor consomes the outer brace. I think the implication here is
that the constructor constructs a value which "wraps" something. I this
case it seems however that this makes things more complicated to the user,
since they have to remember how many braces to put.
> >>
> >>
> >> The task at hand is to delegate construction to one member or another,
disallowing ambiguity. The braced-init-list doesn't seem essential here;
it's not a std::initializer_list and we could have members, generalizing,
being anything including aggregates. You just chose an example using
containers, but a Variant generally doesn't require such.
> >>
> >> Inheriting constructors from a member rather than a base class is
generally useful for adaptor patterns: Private inheritance may be too
messy, yet an adaptor also wants to hide the fact that it is an
intermediary. The existing inheriting constructor semantics seem sufficient
to me, but aggregate support would be nice. In generic template usage you
wouldn't generally be able to detect and prevent a collision. I guess you
don't really perceive that to be a problem.
> >
> >
> > The case of std::optional showed that sometimes you want to "inherit"
constructors from something that is neither a base class nor a member
sub-object. The implementation of optional<T> does not have a member T. It
only has enough raw storage to contain a T. But we still wanted to
"inherit" T's constructors.
> >
> > For the record: I do not intend to propose any such addition to
std::optional; I am just sharing my experience.
> >
>
> Neither do i intend to propose such a thing. I just needed a code example=
..

I understand that there might be cases that then become ambiguous and which
probably is unfortunate.

My gut feeling however is that I would first try to write "{a, b, c}" when
initializing a value or optional value or a variant of values or a logical
aggregate of values or a logical list of values with the "members" a b and
c.

If i have to say {{ ...}} for my taste it depends too much on little
details of constructor parameters or constructor nesting levels. After all
I construct two values of the logically identical kind of value (?) and
have to use different syntaxes.

Are there examples of non-explicit single parameter constructors for which
not consuming the outer brace would cause problems?

I have the gut feeling that defaulting to not consuming the outer brace for
that case could be a good thing.

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

--047d7b6d966ec9366804e4eeb041
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Am 27.08.2013 10:17 schrieb &quot;Johannes Schaub&quot; &lt;<a href=3D"mail=
to:schaub.johannes@googlemail.com">schaub.johannes@googlemail.com</a>&gt;:<=
br>
&gt;<br>
&gt;<br>
&gt; Am 27.08.2013 10:02 schrieb &quot;Andrzej Krzemie=F1ski&quot; &lt;<a h=
ref=3D"mailto:akrzemi1@gmail.com">akrzemi1@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; W dniu wtorek, 27 sierpnia 2013 01:41:14 UTC+2 u=BFytkownik David=
 Krauss napisa=B3:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On Monday, August 26, 2013 1:48:50 PM UTC+8, Johannes Schaub =
wrote:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Sometimes I wonder whether one should be able to declare =
that one constructor (which probably should not be declared &quot;explicit&=
quot;) should not consume braces<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; =A0 =A0 struct Variant {<br>
&gt; &gt;&gt;&gt; =A0 =A0 =A0 Variant(std::map&lt;int, int&gt;);<br>
&gt; &gt;&gt;&gt; =A0 =A0 =A0 Variant(std::vector&lt;string&gt;);<br>
&gt; &gt;&gt;&gt; =A0 =A0 };<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; =A0 =A0 Variant v{{1, 2}, {3, 4}}; // unfortunately, ill-=
formed!<br>
&gt; &gt;&gt;&gt; =A0 =A0 Variant v2{1, 2, 3}; // unfortunately, ill-formed=
!<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; It being a variant, containing the value of either a vect=
or (&quot;list of ints&quot;) or a map (&quot;map of one to another int&quo=
t;), I find it just intuitive that one should be able to list initialize it=
 with &quot;{1, 2, 3}&quot;. However, the constructor consomes the outer br=
ace. I think the implication here is that the constructor constructs a valu=
e which &quot;wraps&quot; something. I this case it seems however that this=
 makes things more complicated to the user, since they have to remember how=
 many braces to put.=A0<br>

&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The task at hand is to delegate construction to one member or=
 another, disallowing ambiguity. The braced-init-list doesn&#39;t seem esse=
ntial here; it&#39;s not a std::initializer_list and we could have members,=
 generalizing, being anything including aggregates. You just chose an examp=
le using containers, but a Variant generally doesn&#39;t require such.<br>

&gt; &gt;&gt;<br>
&gt; &gt;&gt; Inheriting constructors from a member rather than a base clas=
s is generally useful for adaptor patterns: Private inheritance may be too =
messy, yet an adaptor also wants to hide the fact that it is an intermediar=
y. The existing inheriting constructor semantics seem sufficient to me, but=
 aggregate support would be nice. In generic template usage you wouldn&#39;=
t generally be able to detect and prevent a collision. I guess you don&#39;=
t really perceive that to be a problem.<br>

&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; The case of std::optional showed that sometimes you want to &quot=
;inherit&quot; constructors from something that is neither a base class nor=
 a member sub-object. The implementation of optional&lt;T&gt; does not have=
 a member T. It only has enough raw storage to contain a T. But we still wa=
nted to &quot;inherit&quot; T&#39;s constructors.<br>

&gt; &gt;<br>
&gt; &gt; For the record: I do not intend to propose any such addition to s=
td::optional; I am just sharing my experience.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Neither do i intend to propose such a thing. I just needed a code exam=
ple.</p>
<p dir=3D"ltr">I understand that there might be cases that then become ambi=
guous and which probably is unfortunate.</p>
<p dir=3D"ltr">My gut feeling however is that I would first try to write &q=
uot;{a, b, c}&quot; when initializing a value or optional value or a varian=
t of values or a logical aggregate of values or a logical list of values wi=
th the &quot;members&quot; a b and c. </p>

<p dir=3D"ltr">If i have to say {{ ...}} for my taste it depends too much o=
n little details of constructor parameters or constructor nesting levels. A=
fter all I construct two values of the logically identical kind of value (?=
) and have to use different syntaxes.</p>

<p dir=3D"ltr">Are there examples of non-explicit single parameter construc=
tors for which not consuming the outer brace would cause problems? </p>
<p dir=3D"ltr">I have the gut feeling that defaulting to not consuming the =
outer brace for that case could be a good thing.</p>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b6d966ec9366804e4eeb041--

.

------=_Part_1236_19505625.1377615618776
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu wtorek, 27 sierpnia 2013 10:42:58 UTC+2 u=BFytkownik David Krauss=20
napisa=B3:
>
> On Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrzej Krzemie=F1ski wrote=
:
>
> The case of std::optional showed that sometimes you want to "inherit"=20
>> constructors from something that is neither a base class nor a member=20
>> sub-object. The implementation of optional<T> does not have a member T. =
It=20
>> only has enough raw storage to contain a T. But we still wanted to=20
>> "inherit" T's constructors.
>>
>> For the record: I do not intend to propose any such addition to=20
>> std::optional; I am just sharing my experience.
>>
>
> Besides going so far as a real, specific proposal, do you currently feel=
=20
> it would be a good thing?
>

"It would be a good thing" -- but which of the two: changing the=20
constructors of std::optional or extending the "inheriting constructors"=20
feature?

If it is the former, I am against it: std::optional has a default=20
constructor which would collide with the semantics of such inherited=20
default constructor.

If it is the latter, my answer is: I do not know how often one really needs=
=20
such feature.=20

Regards,
&rzej

--=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_1236_19505625.1377615618776
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu wtorek, 27 sierpnia 2013 10:42:58 UTC+2 u=
=BFytkownik David Krauss napisa=B3:<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 Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrze=
j Krzemie=F1ski wrote:<br><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">The case of std::optional showed that sometimes you want to "in=
herit" constructors from something that is neither a base class nor a membe=
r sub-object. The implementation of optional&lt;T&gt; does not have a membe=
r T. It only has enough raw storage to contain a T. But we still wanted to =
"inherit" T's constructors.<br><div><br>For the record: I do not intend to =
propose any such addition to std::optional; I am just sharing my experience=
..</div></div></blockquote><div><br>Besides going so far as a real, specific=
 proposal, do you currently feel it would be a good thing?</div></div></blo=
ckquote><div><br>"It would be a good thing" -- but which of the two: changi=
ng the constructors of std::optional or extending the "inheriting construct=
ors" feature?<br><br>If it is the former, I am against it: std::optional ha=
s a default constructor which would collide with the semantics of such inhe=
rited default constructor.<br><br>If it is the latter, my answer is: I do n=
ot know how often one really needs such feature. <br><br>Regards,<br>&amp;r=
zej<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1236_19505625.1377615618776--

.

------=_Part_2505_964399.1377618699045
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



On Tuesday, August 27, 2013 5:00:18 PM UTC+2, Andrzej Krzemie=F1ski wrote:
>
>
>
> W dniu wtorek, 27 sierpnia 2013 10:42:58 UTC+2 u=BFytkownik David Krauss=
=20
> napisa=B3:
>>
>> On Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrzej Krzemie=F1ski wrot=
e:
>>
>> The case of std::optional showed that sometimes you want to "inherit"=20
>>> constructors from something that is neither a base class nor a member=
=20
>>> sub-object. The implementation of optional<T> does not have a member T.=
 It=20
>>> only has enough raw storage to contain a T. But we still wanted to=20
>>> "inherit" T's constructors.
>>>
>>> For the record: I do not intend to propose any such addition to=20
>>> std::optional; I am just sharing my experience.
>>>
>>
>> Besides going so far as a real, specific proposal, do you currently feel=
=20
>> it would be a good thing?
>>
>
> "It would be a good thing" -- but which of the two: changing the=20
> constructors of std::optional or extending the "inheriting constructors"=
=20
> feature?
>
> If it is the former, I am against it: std::optional has a default=20
> constructor which would collide with the semantics of such inherited=20
> default constructor.
>
>
 Please note that we had the same issue already with initializer list=20
constructors in the past

    struct A {
       A();
       A(std::initializer_list<int>);
    };

    A a{};

This was solved to say that if the class has a default constructor, the=20
object is value initialized (and for overload resolution when there is a=20
parameter of type "A", if the class has a default constructor, the "{}" is=
=20
always taken as an empty argument list when looking for a matching=20
constructor, instead of as the argument list "{}", For "void f(A); f({});",=
=20
hence the only applicable constructor will be "A::A()"). Would this not=20
apply to the hypothetical extension of the "initializer list constructor"=
=20
notion too?=20

I would also rather not call it "inheriting from a member", but instead=20
call it "inheriting from a constructor parameter".=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_2505_964399.1377618699045
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 5:00:18 PM UTC+2, Andr=
zej Krzemie=F1ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><br>W dniu wtorek, 27 sierpnia 2013 10:42:58 UTC+2 u=BFytkow=
nik David Krauss napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrzej Krzemie=F1sk=
i wrote:<br><br><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">Th=
e case of std::optional showed that sometimes you want to "inherit" constru=
ctors from something that is neither a base class nor a member sub-object. =
The implementation of optional&lt;T&gt; does not have a member T. It only h=
as enough raw storage to contain a T. But we still wanted to "inherit" T's =
constructors.<br><div><br>For the record: I do not intend to propose any su=
ch addition to std::optional; I am just sharing my experience.</div></div><=
/blockquote><div><br>Besides going so far as a real, specific proposal, do =
you currently feel it would be a good thing?</div></div></blockquote><div><=
br>"It would be a good thing" -- but which of the two: changing the constru=
ctors of std::optional or extending the "inheriting constructors" feature?<=
br><br>If it is the former, I am against it: std::optional has a default co=
nstructor which would collide with the semantics of such inherited default =
constructor.<br><br></div></div></blockquote><div><br></div><div>&nbsp;Plea=
se note that we had the same issue already with initializer list constructo=
rs in the past</div><div><br></div><div>&nbsp; &nbsp; struct A {</div><div>=
&nbsp; &nbsp; &nbsp; &nbsp;A();</div><div>&nbsp; &nbsp; &nbsp; &nbsp;A(std:=
:initializer_list&lt;int&gt;);</div><div>&nbsp; &nbsp; };</div><div><br></d=
iv><div>&nbsp; &nbsp; A a{};</div><div><br></div><div>This was solved to sa=
y that if the class has a default constructor, the object is value initiali=
zed (and for overload resolution when there is a parameter of type "A", if =
the class has a default constructor, the "{}" is always taken as an empty a=
rgument list when looking for a matching constructor, instead of as the arg=
ument list "{}", For "void f(A); f({});", hence the only applicable constru=
ctor will be "A::A()"). Would this not apply to the hypothetical extension =
of the "initializer list constructor" notion too?&nbsp;</div><div><br></div=
><div>I would also rather not call it "inheriting from a member", but inste=
ad call it "inheriting from a constructor parameter".&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2505_964399.1377618699045--

.

This is a multi-part message in MIME format.
--------------090508090002060101040209
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: quoted-printable

It seems that if the T has a default constructor there will not be=20
possible to construct an disengaged optional<T>.

To me emplace() seems good enough, in which cases would "forwarding of=20
ctor parameters to a member" be important?

On the other hand, can't this be implemented already, along these lines:

template<typename T> class optional {
      optional() : engaged(false) {}
      template<typename... Ps> optional(Ps...), engaged(true) {=20
new(&bytes) T(Ps...); }

private:
     bool engaged;
     char bytes[sizeof(T)];
};

I'm not saying that this is already available but it seems that it can=20
be done with just a library addition. Personally I would not be=20
satisfied with the non-orthogonality created by the default ctor not=20
being forwarded. But there must of course be a way to construct an empty=20
optional for any T.

According to cppreference.com this is already in the optional<> class=20
for C++14, with a special in_place_t object as the first ctor parameter,=20
which I guess is used to create the required difference... and for=20
convenience there is a in_place object of this type to use...

http://en.cppreference.com/w/cpp/utility/optional/optional

So what is the additional suggestion here, I don't see it!


Johannes Schaub skrev 2013-08-27 17:51:
>
>
> On Tuesday, August 27, 2013 5:00:18 PM UTC+2, Andrzej Krzemie=F1ski wrote=
:
>
>
>
>     W dniu wtorek, 27 sierpnia 2013 10:42:58 UTC+2 u=BFytkownik David
>     Krauss napisa=B3:
>
>         On Tuesday, August 27, 2013 4:02:07 PM UTC+8, Andrzej
>         Krzemie=F1ski wrote:
>
>             The case of std::optional showed that sometimes you want
>             to "inherit" constructors from something that is neither a
>             base class nor a member sub-object. The implementation of
>             optional<T> does not have a member T. It only has enough
>             raw storage to contain a T. But we still wanted to
>             "inherit" T's constructors.
>
>             For the record: I do not intend to propose any such
>             addition to std::optional; I am just sharing my experience.
>
>
>         Besides going so far as a real, specific proposal, do you
>         currently feel it would be a good thing?
>
>
>     "It would be a good thing" -- but which of the two: changing the
>     constructors of std::optional or extending the "inheriting
>     constructors" feature?
>
>     If it is the former, I am against it: std::optional has a default
>     constructor which would collide with the semantics of such
>     inherited default constructor.
>
>
>  Please note that we had the same issue already with initializer list=20
> constructors in the past
>
>     struct A {
>        A();
>        A(std::initializer_list<int>);
>     };
>
>     A a{};
>
> This was solved to say that if the class has a default constructor,=20
> the object is value initialized (and for overload resolution when=20
> there is a parameter of type "A", if the class has a default=20
> constructor, the "{}" is always taken as an empty argument list when=20
> looking for a matching constructor, instead of as the argument list=20
> "{}", For "void f(A); f({});", hence the only applicable constructor=20
> will be "A::A()"). Would this not apply to the hypothetical extension=20
> of the "initializer list constructor" notion too?
>
> I would also rather not call it "inheriting from a member", but=20
> instead call it "inheriting from a constructor parameter".
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com

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

--------------090508090002060101040209
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-2"
      http-equiv=3D"Content-Type">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    It seems that if the T has a default constructor there will not be
    possible to construct an disengaged optional&lt;T&gt;.<br>
    <br>
    To me emplace() seems good enough, in which cases would "forwarding
    of ctor parameters to a member" be important?<br>
    <br>
    On the other hand, can't this be implemented already, along these
    lines:<br>
    <br>
    template&lt;typename T&gt; class optional {<br>
    =A0=A0=A0=A0 optional() : engaged(false) {}<br>
    =A0=A0=A0=A0 template&lt;typename... Ps&gt; optional(Ps...), engaged(tr=
ue) {
    new(&amp;bytes) T(Ps...); }<br>
    <br>
    private:<br>
    =A0=A0=A0 bool engaged;<br>
    =A0=A0=A0 char bytes[sizeof(T)];<br>
    };<br>
    <br>
    I'm not saying that this is already available but it seems that it
    can be done with just a library addition. Personally I would not be
    satisfied with the non-orthogonality created by the default ctor not
    being forwarded. But there must of course be a way to construct an
    empty optional for any T.<br>
    <br>
    According to cppreference.com this is already in the
    optional&lt;&gt; class for C++14, with a special in_place_t object
    as the first ctor parameter, which I guess is used to create the
    required difference... and for convenience there is a in_place
    object of this type to use...<br>
    <br>
    <a href=3D"http://en.cppreference.com/w/cpp/utility/optional/optional">=
http://en.cppreference.com/w/cpp/utility/optional/optional</a><br>
    <br>
    So what is the additional suggestion here, I don't see it!<br>
    <br>
    <br>
    <div class=3D"moz-cite-prefix">Johannes Schaub skrev 2013-08-27 17:51:<=
br>
    </div>
    <blockquote
      cite=3D"mid:ccb7a214-be86-4613-9f15-939330e56998@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Tuesday, August 27, 2013 5:00:18 PM UTC+2, Andrzej
        Krzemie=F1ski 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"><br>
            <br>
            W dniu wtorek, 27 sierpnia 2013 10:42:58 UTC+2 u=BFytkownik
            David Krauss napisa=B3:
            <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 Tuesday, August 27, 2013 4:02:07 PM
                UTC+8, Andrzej Krzemie=F1ski wrote:<br>
                <br>
                <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">The case of std::optional showed that
                    sometimes you want to "inherit" constructors from
                    something that is neither a base class nor a member
                    sub-object. The implementation of optional&lt;T&gt;
                    does not have a member T. It only has enough raw
                    storage to contain a T. But we still wanted to
                    "inherit" T's constructors.<br>
                    <div><br>
                      For the record: I do not intend to propose any
                      such addition to std::optional; I am just sharing
                      my experience.</div>
                  </div>
                </blockquote>
                <div><br>
                  Besides going so far as a real, specific proposal, do
                  you currently feel it would be a good thing?</div>
              </div>
            </blockquote>
            <div><br>
              "It would be a good thing" -- but which of the two:
              changing the constructors of std::optional or extending
              the "inheriting constructors" feature?<br>
              <br>
              If it is the former, I am against it: std::optional has a
              default constructor which would collide with the semantics
              of such inherited default constructor.<br>
              <br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>=A0Please note that we had the same issue already with
          initializer list constructors in the past</div>
        <div><br>
        </div>
        <div>=A0 =A0 struct A {</div>
        <div>=A0 =A0 =A0 =A0A();</div>
        <div>=A0 =A0 =A0 =A0A(std::initializer_list&lt;int&gt;);</div>
        <div>=A0 =A0 };</div>
        <div><br>
        </div>
        <div>=A0 =A0 A a{};</div>
        <div><br>
        </div>
        <div>This was solved to say that if the class has a default
          constructor, the object is value initialized (and for overload
          resolution when there is a parameter of type "A", if the class
          has a default constructor, the "{}" is always taken as an
          empty argument list when looking for a matching constructor,
          instead of as the argument list "{}", For "void f(A); f({});",
          hence the only applicable constructor will be "A::A()"). Would
          this not apply to the hypothetical extension of the
          "initializer list constructor" notion too?=A0</div>
        <div><br>
        </div>
        <div>I would also rather not call it "inheriting from a member",
          but instead call it "inheriting from a constructor
          parameter".=A0</div>
      </div>
      -- <br>
      =A0<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 class=3D"moz-txt-link-abbreviated" href=3D"mailto=
:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org=
</a>.<br>
      To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
    <pre class=3D"moz-signature" cols=3D"72">--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
<a class=3D"moz-txt-link-abbreviated" href=3D"http://www.beamways.com">www.=
beamways.com</a>
</pre>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--------------090508090002060101040209--

.

2013/8/27 Bengt Gustafsson <bengt.gustafsson@beamways.com>:
> It seems that if the T has a default constructor there will not be possible
> to construct an disengaged optional<T>.

I might miss some context from a previous message for that, but why do
you think that this assertion is correct?

struct DefaultConstructible {};
std::optional<DefaultConstructible> empty; // disengaged: OK

[I suspect that your claim was referring to Johannes' proposal, but I
miss some details to understand what you are trying to say here]

- Daniel

--

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

.

Yes, I was refering to the suggestion to forward ctor parameters to the=20
actual object, which would raise my question. Now, if the draft standard=20
is consistent with cppreference.com the problem seems tha have been=20
solved in a way that I would be happy with.

Daniel Kr=FCgler skrev 2013-08-27 20:31:
> 2013/8/27 Bengt Gustafsson <bengt.gustafsson@beamways.com>:
>> It seems that if the T has a default constructor there will not be possi=
ble
>> to construct an disengaged optional<T>.
> I might miss some context from a previous message for that, but why do
> you think that this assertion is correct?
>
> struct DefaultConstructible {};
> std::optional<DefaultConstructible> empty; // disengaged: OK
>
> [I suspect that your claim was referring to Johannes' proposal, but I
> miss some details to understand what you are trying to say here]
>
> - Daniel
>

--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com

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

.