Topic: default' to initialize Variables, Types and Parameters
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Thu, 9 Apr 2015 06:02:35 -0700 (PDT)
Raw View
------=_Part_86_1938615364.1428584555835
Content-Type: multipart/alternative;
boundary="----=_Part_87_686530464.1428584555835"
------=_Part_87_686530464.1428584555835
Content-Type: text/plain; charset=UTF-8
*Problem:*
I think we often write things like:
void foo( weak_ptr<ClassName> param = weak_ptr<ClassName>() ){
...
}
So a shorter way of writing the typename again and adding some '()' would be
to just write something like:
void foo( weak_ptr<ClassName> param = default ){
...
}
I think it makes things much clearer to understand and faster to type.
The reason why '= {}' is not enough is the following:
1. It only allows for implicit initialization and
2. it does not work for ctors that take initializer_list's
3. it behaves a bit counter intuitive, since assigning some kind of "empty
list" is not what is actually done.
4. Using 'default' would be much mightier and could simplify function
calls, as you will see later on
*Usages:*
A proposal would allow the use of this syntax at
1. Optional Parameter initialization
2. Return Values *"return default;"*
3. a normal Variable Declaration, even though it does not simplify anything.
But instead of restricting the use to those 3 locations...
*4. Parameter-Initialization:*
If functions or templates specify default/fallback values for their
parameters,
they cannot be referenced by the caller afterwards.
The only option to use the fallback value at the moment, is to look it up
at the functions'/templates' declaration.
=> But what if that declaration changes in a later update?
So, whenever you want to pass, whatever value or type the function/template
suggests as fallback,
you could now write 'default' and use the fallback type or value specified
by the function/template declaration!
*This enormously simplificates optional parameters in general:*
One could indicate he wants to use the fallback specification
at the first three parameters of a function and specify only the last
parameter.
*If there is no fallback specification*, the default-ctor of the parameter
type is called (in case it's a variable being initialized).
If it's a type, a compile-time-error is thrown, or the type defaults to int
(which is what C suggests ;-)
*Note:*
"= default" as language construct can of course not be overloaded using
"operator=" ;-)
Tell me what you think and whether it makes sence to write a proposal.
Improvements are welcome!
Cheers,
Jakob Riedle
--
---
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_87_686530464.1428584555835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><u><b>Problem:</b></u></div><div><br></div>I think we=
often write things like:<div><br></div><div class=3D"prettyprint" style=3D=
"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> weak_ptr</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">ClassName</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> param </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> weak_ptr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">ClassName</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">>()</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">){</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
/div></code></div><div><br></div><div><br></div><div>So a shorter way of wr=
iting the typename again and adding some '()' would be</div><div>to just wr=
ite something like:</div><div><br></div><div><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> weak_ptr</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">ClassName</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> param </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">default</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"><b=
r> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
></div></code></div></div><div><br></div><div>I think it makes things much =
clearer to understand and faster to type.</div><div><br></div><div>The reas=
on why '=3D {}' is not enough is the following:</div><div>1. It only allows=
for implicit initialization and</div><div>2. it does not work for ctors th=
at take initializer_list's</div><div>3. it behaves a bit counter intuitive,=
since assigning some kind of "empty list" is not what is actually done.</d=
iv><div>4. Using 'default' would be much mightier and could simplify functi=
on calls, as you will see later on</div><div><br></div><div><br></div><div>=
<u><b>Usages:</b></u></div><div><br></div><div>A proposal would allow the u=
se of this syntax at</div><div>1. Optional Parameter initialization</div><d=
iv>2. Return Values <b>"return default;"</b></div><div>3. a normal Variable=
Declaration, even though it does not simplify anything.</div><div><br></di=
v><div>But instead of restricting the use to those 3 locations...</div><div=
><br></div><div><b>4. Parameter-Initialization:</b><br></div><div><b><br></=
b></div><div>If functions or templates specify default/fallback values for =
their parameters,</div><div>they cannot be referenced by the caller afterwa=
rds.</div><div>The only option to use the fallback value at the moment, is =
to look it up at the functions'/templates' declaration.</div><div>=3D> B=
ut what if that declaration changes in a later update?</div><div><br></div>=
<div>So, whenever you want to pass, whatever value or type the function/tem=
plate suggests as fallback,</div><div>you could now write 'default' and use=
the fallback type or value specified by the function/template declaration!=
</div><div><br></div><div><u>This enormously simplificates optional paramet=
ers in general:</u></div><div><br></div><div>One could indicate he wants to=
use the fallback specification</div><div>at the first three parameters of =
a function and specify only the last parameter.</div><div><br></div><div><b=
>If there is no fallback specification</b>, the default-ctor of the paramet=
er type is called (in case it's a variable being initialized).</div><div>If=
it's a type, a compile-time-error is thrown, or the type defaults to int (=
which is what C suggests ;-)</div><div><br></div><div><br></div><div><b>Not=
e:</b></div><div><br></div><div>"=3D default" as language construct can of =
course not be overloaded using "operator=3D" ;-)</div><div><br></div><div><=
br></div><div>Tell me what you think and whether it makes sence to write a =
proposal.</div><div>Improvements are welcome!</div><div><br></div><div><br>=
</div><div>Cheers,</div><div>Jakob Riedle</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_87_686530464.1428584555835--
------=_Part_86_1938615364.1428584555835--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Thu, 9 Apr 2015 14:56:27 +0100
Raw View
--001a11347da69b63f605134b03cb
Content-Type: text/plain; charset=UTF-8
I imagine that the intention is that ' = default' does value-initialization
of the variable (which is what 'T()' does). A bit funny that ' = default'
does not do default-initialization but value-initialization, which is
clearly not the "default" form of initialization in the language... but I
think this is a good idea. Also regarding the comment on 'operator=' not
being overloadable for this case, I believe it should only be allowed for
initialization (copy-initialization), rather than assignment:
T a = default; // T a = T{};
a = default; // error
On Thu, Apr 9, 2015 at 2:02 PM, Jakob Riedle <jakob.riedle@gmail.com> wrote:
> *Problem:*
>
> I think we often write things like:
>
> void foo( weak_ptr<ClassName> param = weak_ptr<ClassName>() ){
> ...
> }
>
>
> So a shorter way of writing the typename again and adding some '()' would
> be
> to just write something like:
>
> void foo( weak_ptr<ClassName> param = default ){
> ...
> }
>
> I think it makes things much clearer to understand and faster to type.
>
> The reason why '= {}' is not enough is the following:
> 1. It only allows for implicit initialization and
> 2. it does not work for ctors that take initializer_list's
> 3. it behaves a bit counter intuitive, since assigning some kind of "empty
> list" is not what is actually done.
> 4. Using 'default' would be much mightier and could simplify function
> calls, as you will see later on
>
>
> *Usages:*
>
> A proposal would allow the use of this syntax at
> 1. Optional Parameter initialization
> 2. Return Values *"return default;"*
> 3. a normal Variable Declaration, even though it does not simplify
> anything.
>
> But instead of restricting the use to those 3 locations...
>
> *4. Parameter-Initialization:*
>
> If functions or templates specify default/fallback values for their
> parameters,
> they cannot be referenced by the caller afterwards.
> The only option to use the fallback value at the moment, is to look it up
> at the functions'/templates' declaration.
> => But what if that declaration changes in a later update?
>
> So, whenever you want to pass, whatever value or type the
> function/template suggests as fallback,
> you could now write 'default' and use the fallback type or value specified
> by the function/template declaration!
>
> *This enormously simplificates optional parameters in general:*
>
> One could indicate he wants to use the fallback specification
> at the first three parameters of a function and specify only the last
> parameter.
>
> *If there is no fallback specification*, the default-ctor of the
> parameter type is called (in case it's a variable being initialized).
> If it's a type, a compile-time-error is thrown, or the type defaults to
> int (which is what C suggests ;-)
>
>
> *Note:*
>
> "= default" as language construct can of course not be overloaded using
> "operator=" ;-)
>
>
> Tell me what you think and whether it makes sence to write a proposal.
> Improvements are welcome!
>
>
> Cheers,
> Jakob Riedle
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11347da69b63f605134b03cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I imagine that the intention is that ' =3D default'=
; does value-initialization of the variable (which is what 'T()' do=
es). A bit funny that ' =3D default' does not do default-initializa=
tion but value-initialization, which is clearly not the "default"=
form of initialization in the language... but I think this is a good idea.=
=C2=A0 Also regarding the comment on 'operator=3D' not being overlo=
adable for this case, I believe it should only be allowed for initializatio=
n (copy-initialization), rather than assignment:<br><br>T a =3D default; //=
T a =3D T{};<br>a =3D default; =C2=A0 =C2=A0// error<br><br><br></div><div=
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Apr 9, 2015 a=
t 2:02 PM, Jakob Riedle <span dir=3D"ltr"><<a href=3D"mailto:jakob.riedl=
e@gmail.com" target=3D"_blank">jakob.riedle@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><u><b>Problem:</b>=
</u></div><div><br></div>I think we often write things like:<div><br></div>=
<div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgr=
ound-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">void</sp=
an><span style=3D"color:#000"> foo</span><span style=3D"color:#660">(</span=
><span style=3D"color:#000"> weak_ptr</span><span style=3D"color:#660"><=
</span><span style=3D"color:#606">ClassName</span><span style=3D"color:#660=
">></span><span style=3D"color:#000"> param </span><span style=3D"color:=
#660">=3D</span><span style=3D"color:#000"> weak_ptr</span><span style=3D"c=
olor:#660"><</span><span style=3D"color:#606">ClassName</span><span styl=
e=3D"color:#660">>()</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">){</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </sp=
an><span style=3D"color:#660">...</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#660">}</span></div></code></div><div><br></div><di=
v><br></div><div>So a shorter way of writing the typename again and adding =
some '()' would be</div><div>to just write something like:</div><di=
v><br></div><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:=
break-word;background-color:rgb(250,250,250)"><code><div><span style=3D"col=
or:#008">void</span><span style=3D"color:#000"> foo</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000"> weak_ptr</span><span style=3D=
"color:#660"><</span><span style=3D"color:#606">ClassName</span><span st=
yle=3D"color:#660">></span><span style=3D"color:#000"> param </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#008">default</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">){</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color:#660">...</span><span style=3D"color:#000"><br>=
</span><span style=3D"color:#660">}</span></div></code></div></div><div><br=
></div><div>I think it makes things much clearer to understand and faster t=
o type.</div><div><br></div><div>The reason why '=3D {}' is not eno=
ugh is the following:</div><div>1. It only allows for implicit initializati=
on and</div><div>2. it does not work for ctors that take initializer_list&#=
39;s</div><div>3. it behaves a bit counter intuitive, since assigning some =
kind of "empty list" is not what is actually done.</div><div>4. U=
sing 'default' would be much mightier and could simplify function c=
alls, as you will see later on</div><div><br></div><div><br></div><div><u><=
b>Usages:</b></u></div><div><br></div><div>A proposal would allow the use o=
f this syntax at</div><div>1. Optional Parameter initialization</div><div>2=
.. Return Values <b>"return default;"</b></div><div>3. a normal Va=
riable Declaration, even though it does not simplify anything.</div><div><b=
r></div><div>But instead of restricting the use to those 3 locations...</di=
v><div><br></div><div><b>4. Parameter-Initialization:</b><br></div><div><b>=
<br></b></div><div>If functions or templates specify default/fallback value=
s for their parameters,</div><div>they cannot be referenced by the caller a=
fterwards.</div><div>The only option to use the fallback value at the momen=
t, is to look it up at the functions'/templates' declaration.</div>=
<div>=3D> But what if that declaration changes in a later update?</div><=
div><br></div><div>So, whenever you want to pass, whatever value or type th=
e function/template suggests as fallback,</div><div>you could now write =
9;default' and use the fallback type or value specified by the function=
/template declaration!</div><div><br></div><div><u>This enormously simplifi=
cates optional parameters in general:</u></div><div><br></div><div>One coul=
d indicate he wants to use the fallback specification</div><div>at the firs=
t three parameters of a function and specify only the last parameter.</div>=
<div><br></div><div><b>If there is no fallback specification</b>, the defau=
lt-ctor of the parameter type is called (in case it's a variable being =
initialized).</div><div>If it's a type, a compile-time-error is thrown,=
or the type defaults to int (which is what C suggests ;-)</div><div><br></=
div><div><br></div><div><b>Note:</b></div><div><br></div><div>"=3D def=
ault" as language construct can of course not be overloaded using &quo=
t;operator=3D" ;-)</div><div><br></div><div><br></div><div>Tell me wha=
t you think and whether it makes sence to write a proposal.</div><div>Impro=
vements are welcome!</div><div><br></div><div><br></div><div>Cheers,</div><=
div>Jakob Riedle</div></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11347da69b63f605134b03cb--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 09 Apr 2015 10:55:22 -0400
Raw View
On 2015-04-09 09:02, Jakob Riedle wrote:
> *Problem:*
>
> I think we often write things like:
>
> void foo( weak_ptr<ClassName> param = weak_ptr<ClassName>() ){
> ...
> }
>
> So a shorter way of writing the typename again and adding some '()' would be
> to just write something like:
>
> void foo( weak_ptr<ClassName> param = default ){
> ...
> }
>
> The reason why '= {}' is not enough is the following:
> 1. It only allows for implicit initialization and
Sorry... what's the difference?
> 2. it does not work for ctors that take initializer_list's
Ahem. "[T]he standard is explicit that an empty { } list means to call
the default constructor if available."
(See http://herbsutter.com/2013/05/09/gotw-1-solution/)
> 3. it behaves a bit counter intuitive, since assigning some kind of "empty
> list" is not what is actually done.
Er... no? It's performing default construction, eliding the type name.
Consider (parameters):
Foo = Foo(5, 2.1, "hello")
Foo = Foo{5, 2.1, "hello"} // same thing
Foo = {5, 2.1, "hello"} // still the same thing
It seems that you are not used to uniform initialization.
> 4. Using 'default' would be much mightier and could simplify function
> calls, as you will see later on
Now *that* has some potential...
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 10 Apr 2015 07:30:23 +0200
Raw View
Le 09/04/15 16:55, Matthew Woehlke a =C3=A9crit :
> On 2015-04-09 09:02, Jakob Riedle wrote:
>> *Problem:*
>>
>> I think we often write things like:
>>
>> void foo( weak_ptr<ClassName> param =3D weak_ptr<ClassName>() ){
>> ...
>> }
>>
>> So a shorter way of writing the typename again and adding some '()' woul=
d be
>> to just write something like:
>>
>> void foo( weak_ptr<ClassName> param =3D default ){
>> ...
>> }
>>
>> The reason why '=3D {}' is not enough is the following:
>> 1. It only allows for implicit initialization and
> Sorry... what's the difference?
>
I'm not a language expert, but I'm getting
struct E {
explicit E() {}
};
struct I {
I() {}
};
struct IIL {
IIL(std::initializer_list<int>) {}
};
struct EIL {
explicit EIL(std::initializer_list<int>) {}
};
void f(I p =3D {}) {}
//void f(E p =3D {}); // compile error
void f(IIL p =3D {}){}
//void f(EIL p =3D {}){} // compile error
=3D=3D=3D=3D=3D=3D=3D=3D=3D
erreur: converting to =E2=80=98E=E2=80=99 from initializer list would use e=
xplicit=20
constructor =E2=80=98E::E()=E2=80=99
void f(E p =3D {});
erreur: converting to =E2=80=98EIL=E2=80=99 from initializer list would use=
explicit=20
constructor =E2=80=98EIL::EIL(std::initializer_list<int>)=E2=80=99
void f(EIL p =3D {}){}
>> 2. it does not work for ctors that take initializer_list's
> Ahem. "[T]he standard is explicit that an empty { } list means to call
> the default constructor if available."
>
> (See /)
See example above. This depends on whether the constructor is implicit=20
or explicit.
Vicente
--=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/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 10 Apr 2015 08:22:32 +0200
Raw View
This is a multi-part message in MIME format.
--------------010506000604090005040808
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/04/15 15:02, Jakob Riedle a =C3=A9crit :
> _*Problem:*_
>
> I think we often write things like:
>
> |
> voidfoo(weak_ptr<ClassName>param =3Dweak_ptr<ClassName>()){
> ...
> }
> |
>
>
> So a shorter way of writing the typename again and adding some '()'=20
> would be
> to just write something like:
>
> |
> voidfoo(weak_ptr<ClassName>param =3Ddefault){
> ...
> }
> |
>
> I think it makes things much clearer to understand and faster to type.
>
> The reason why '=3D {}' is not enough is the following:
> 1. It only allows for implicit initialization and
> 2. it does not work for ctors that take initializer_list's
> 3. it behaves a bit counter intuitive, since assigning some kind of=20
> "empty list" is not what is actually done.
> 4. Using 'default' would be much mightier and could simplify function=20
> calls, as you will see later on
>
>
> _*Usages:*_
>
> A proposal would allow the use of this syntax at
> 1. Optional Parameter initialization
> 2. Return Values *"return default;"*
> 3. a normal Variable Declaration, even though it does not simplify=20
> anything.
>
There was a proposal "Let {expr} Be Explicit" [1] and its associated=20
counter-proposals "Response To: Let |return {expr}| Be Explicit" [2]=20
and "Another response to N4074=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4074.pdf>:explici=
t=20
should never be implicit" [3].
Your proposal could be renamed "Let default Be Explicit Default=20
Constructor".
As your proposal is restricted to default constructors, it should be=20
less controversial than N4074.
I would suggest to replace default by explicit {} "Let explicit {} Be=20
Explicit Default Constructor".
Note that the following works already
struct explicit_d {};
struct E {
explicit E() {}
E(explicit_d) {}
};
void f(E p =3D explicit_d{}); // OK
//void f(E p =3D {}); // compile error
We could also consider "Let *explicit {expr}* Be Explicit Constructor".
> But instead of restricting the use to those 3 locations...
>
> *4. Parameter-Initialization:*
> *
> *
> If functions or templates specify default/fallback values for their=20
> parameters,
> they cannot be referenced by the caller afterwards.
> The only option to use the fallback value at the moment, is to look it=20
> up at the functions'/templates' declaration.
> =3D> But what if that declaration changes in a later update?
>
> So, whenever you want to pass, whatever value or type the=20
> function/template suggests as fallback,
> you could now write 'default' and use the fallback type or value=20
> specified by the function/template declaration!
>
> _This enormously simplificates optional parameters in general:_
>
> One could indicate he wants to use the fallback specification
> at the first three parameters of a function and specify only the last=20
> parameter.
I think that this is a quite different feature, IIUC, it is independent=20
of how the parameters have been defaulted.
>
> *If there is no fallback specification*, the default-ctor of the=20
> parameter type is called (in case it's a variable being initialized).
> If it's a type, a compile-time-error is thrown, or the type defaults=20
> to int (which is what C suggests ;-)
>
I don't think you need this also. The caller either shoud specify the he=20
wants a explicit default constructor using explicit {} or the fall-back=20
value.
Best,
Vicente
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4074.pdf
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4094.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4131.html
--=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/.
--------------010506000604090005040808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 09/04/15 15:02, Jakob Riedle a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:8ab4eb41-97ff-4a24-a756-886a33794558@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><u><b>Problem:</b></u></div>
<div><br>
</div>
I think we often write things like:
<div><br>
</div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
187); word-wrap: break-word; background-color: rgb(250, 250,
250);"><code class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify">
weak_ptr</span><span style=3D"color: #660;"
class=3D"styled-by-prettify"><</span><span
style=3D"color: #606;" class=3D"styled-by-prettify">ClassNa=
me</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">></s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> param =
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">
weak_ptr</span><span style=3D"color: #660;"
class=3D"styled-by-prettify"><</span><span
style=3D"color: #606;" class=3D"styled-by-prettify">ClassNa=
me</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">){</spa=
n><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 =C2=A0 </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"styled-by-prettify">}</span></div>
</code></div>
<div><br>
</div>
<div><br>
</div>
<div>So a shorter way of writing the typename again and adding
some '()' would be</div>
<div>to just write something like:</div>
<div><br>
</div>
<div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187,
187, 187); word-wrap: break-word; background-color: rgb(250,
250, 250);"><code class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> foo<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">
weak_ptr</span><span style=3D"color: #660;"
class=3D"styled-by-prettify"><</span><span
style=3D"color: #606;" class=3D"styled-by-prettify">Class=
Name</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">><=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> para=
m
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or:
#000;" class=3D"styled-by-prettify"> </span><span
style=3D"color: #008;" class=3D"styled-by-prettify">defau=
lt</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">){</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 =C2=A0 </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"styled-by-prettify">}</span></div>
</code></div>
</div>
<div><br>
</div>
<div>I think it makes things much clearer to understand and
faster to type.</div>
<div><br>
</div>
<div>The reason why '=3D {}' is not enough is the following:</div>
<div>1. It only allows for implicit initialization and</div>
<div>2. it does not work for ctors that take initializer_list's</di=
v>
<div>3. it behaves a bit counter intuitive, since assigning some
kind of "empty list" is not what is actually done.</div>
<div>4. Using 'default' would be much mightier and could
simplify function calls, as you will see later on</div>
<div><br>
</div>
<div><br>
</div>
<div><u><b>Usages:</b></u></div>
<div><br>
</div>
<div>A proposal would allow the use of this syntax at</div>
<div>1. Optional Parameter initialization</div>
<div>2. Return Values <b>"return default;"</b></div>
<div>3. a normal Variable Declaration, even though it does not
simplify anything.</div>
<div><br>
</div>
</div>
</blockquote>
There was a proposal "Let {expr} Be Explicit"
[1] and=C2=A0 its associated counter-proposals "Response To: Let <code>=
return
{expr}</code> Be Explicit"=C2=A0 [2] and "Another response to <a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4074=
..pdf">N4074</a>:explicit
should never be implicit"=C2=A0 [3].<br>
Your proposal could be renamed "Let default Be Explicit Default
Constructor".<br>
=C2=A0<br>
As your proposal is restricted to default constructors, it should be
less controversial than N4074.<br>
I would suggest to replace default by explicit {} "Let explicit {}
Be Explicit Default Constructor".<br>
<br>
Note that the following works already<br>
<br>
struct explicit_d {};<br>
<br>
struct E {<br>
=C2=A0 explicit E() {}<br>
=C2=A0 E(explicit_d) {}<br>
};<br>
<br>
void f(E p =3D explicit_d{}); // OK<br>
//void f(E p =3D {}); // compile error<br>
<br>
<br>
We could also consider "Let <b>explicit {expr}</b> Be Explicit
Constructor".<br>
<blockquote
cite=3D"mid:8ab4eb41-97ff-4a24-a756-886a33794558@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>But instead of restricting the use to those 3 locations...</di=
v>
<div><br>
</div>
<div><b>4. Parameter-Initialization:</b><br>
</div>
<div><b><br>
</b></div>
<div>If functions or templates specify default/fallback values
for their parameters,</div>
<div>they cannot be referenced by the caller afterwards.</div>
<div>The only option to use the fallback value at the moment, is
to look it up at the functions'/templates' declaration.</div>
<div>=3D> But what if that declaration changes in a later
update?</div>
<div><br>
</div>
<div>So, whenever you want to pass, whatever value or type the
function/template suggests as fallback,</div>
<div>you could now write 'default' and use the fallback type or
value specified by the function/template declaration!</div>
<div><br>
</div>
<div><u>This enormously simplificates optional parameters in
general:</u></div>
<div><br>
</div>
<div>One could indicate he wants to use the fallback
specification</div>
<div>at the first three parameters of a function and specify
only the last parameter.</div>
</div>
</blockquote>
I think that this is a quite different feature, IIUC, it is
independent of how the parameters have been defaulted.<br>
<blockquote
cite=3D"mid:8ab4eb41-97ff-4a24-a756-886a33794558@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><b>If there is no fallback specification</b>, the
default-ctor of the parameter type is called (in case it's a
variable being initialized).</div>
<div>If it's a type, a compile-time-error is thrown, or the type
defaults to int (which is what C suggests ;-)</div>
<br>
</div>
</blockquote>
<br>
I don't think you need this also. The caller either shoud specify
the he wants a explicit default constructor using explicit {} or the
fall-back value.<br>
<br>
Best,<br>
Vicente<br>
<br>
<a class=3D"moz-txt-link-freetext"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4074=
..pdf">[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4074.pdf</a>
<br>
[2]
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2014/n4094.html">http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2014/n4094.html</a><br>
[3] <a class=3D"moz-txt-link-freetext"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4131.html"=
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4131.html</a>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010506000604090005040808--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Thu, 9 Apr 2015 23:56:16 -0700 (PDT)
Raw View
------=_Part_37_159224081.1428648976218
Content-Type: multipart/alternative;
boundary="----=_Part_38_54144652.1428648976223"
------=_Part_38_54144652.1428648976223
Content-Type: text/plain; charset=UTF-8
>
> We could also consider "Let *explicit {expr}* Be Explicit Constructor".
But insn't that exactly, what N4131 wanted to prohibit?
Note that the following works already
>
> struct explicit_d {};
>
> struct E {
> explicit E() {}
> E(explicit_d) {}
> };
>
> void f(E p = explicit_d{}); // OK
> //void f(E p = {}); // compile error
>
That's one of the reasons to write a proposal.
I think that this is a quite different feature, IIUC, it is independent of
> how the parameters have been defaulted.
>
>
> *If there is no fallback specification*, the default-ctor of the
> parameter type is called (in case it's a variable being initialized).
> If it's a type, a compile-time-error is thrown, or the type defaults to
> int (which is what C suggests ;-)
>
>
> I don't think you need this also. The caller either shoud specify the he
> wants a explicit default constructor using explicit {} or the fall-back
> value.
>
The cool thing about it is, that the compiler takes the value that is being
considered the 'default' value by the library developer at this place;
The caller doesn't have to worry.
--
---
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_38_54144652.1428648976223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;">We could also consider "Let&n=
bsp;<b>explicit {expr}</b> Be Explicit Constructor".</blockquote><div>=
<br></div><div>But insn't that exactly, what N4131 wanted to prohibit?</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
Note that the following works already<br>
<br>
struct explicit_d {};<br>
<br>
struct E {<br>
explicit E() {}<br>
E(explicit_d) {}<br>
};<br>
<br>
void f(E p =3D explicit_d{}); // OK<br>
//void f(E p =3D {}); // compile error<br></div></blockquote><div><br><=
/div><div>That's one of the reasons to write a proposal.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" tex=
t=3D"#000000">I think that this is a quite different feature, IIUC, it is
independent of how the parameters have been defaulted.<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><b>If there is no fallback specification</b>, the
default-ctor of the parameter type is called (in case it's a
variable being initialized).</div>
<div>If it's a type, a compile-time-error is thrown, or the type
defaults to int (which is what C suggests ;-)</div>
<br>
</div>
</blockquote>
<br>
I don't think you need this also. The caller either shoud specify
the he wants a explicit default constructor using explicit {} or the
fall-back value.<br></div></blockquote><div><br></div><div>The cool thi=
ng about it is, that the compiler takes the value that is being considered =
the 'default' value by the library developer at this place;</div><div>The c=
aller doesn't have to worry.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_38_54144652.1428648976223--
------=_Part_37_159224081.1428648976218--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Fri, 10 Apr 2015 00:23:23 -0700 (PDT)
Raw View
------=_Part_518_587676405.1428650603486
Content-Type: multipart/alternative;
boundary="----=_Part_519_1683981752.1428650603486"
------=_Part_519_1683981752.1428650603486
Content-Type: text/plain; charset=UTF-8
Am Freitag, 10. April 2015 08:22:34 UTC+2 schrieb Vicente J. Botet Escriba:
We could also consider "Let *explicit {expr}* Be Explicit Constructor".
If I rethink this, actually, we *don't have to allow 'default' to use
explicit default constructors*.
I think, there are only extremely rare cases out there, where the
default-ctor has been made explicit,
because making ctors explicit is mostly for the sake of *unwanted implicit
conversion*.
The default ctor doesn't do conversions, so you will only stumble on
explicit default-ctors rarely.
For those cases, it is ok to write out the full typename, for whatever
reason the class author wanted that.
>
> I think that this is a quite different feature, IIUC, it is independent of
>> how the parameters have been defaulted.
>>
>>
>> *If there is no fallback specification*, the default-ctor of the
>> parameter type is called (in case it's a variable being initialized).
>> If it's a type, a compile-time-error is thrown, or the type defaults to
>> int (which is what C suggests ;-)
>>
>>
>> I don't think you need this also. The caller either shoud specify the he
>> wants a explicit default constructor using explicit {} or the fall-back
>> value.
>>
>
> The improvement here is, that the compiler takes the value that is being
considered the 'default' value by the library developer at this place;
The caller doesn't have to worry.
--
---
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_519_1683981752.1428650603486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Freitag, 10. April 2015 08:22:34 UTC+2 schrieb =
Vicente J. Botet Escriba:<div><br></div><div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left=
-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">W=
e could also consider "Let <b>explicit {expr}</b> Be Explicit Con=
structor".</blockquote><div><br></div><div>If I rethink this, actually, we =
<b>don't have to allow 'default' to use explicit default constructors</b>.<=
/div><div>I think, there are only extremely rare cases out there, where the=
default-ctor has been made explicit,</div><div>because making ctors explic=
it is mostly for the sake of <i>unwanted implicit conversion</i>.</div><div=
><br></div><div>The default ctor doesn't do conversions, so you will only s=
tumble on explicit default-ctors rarely.</div><div>For those cases, it is o=
k to write out the full typename, for whatever reason the class author want=
ed that.</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"></div></blockquote><div> &=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FF=
FFFF" text=3D"#000000"><div class=3D"G3J0AAD-gd-a"><div tabindex=3D"0" clas=
s=3D"G3J0AAD-nb-P"><div style=3D"overflow: auto;"><div dir=3D"ltr"><div cla=
ss=3D"G3J0AAD-xb-b" style=3D"margin: 0px; padding: 0px; border: 0px; vertic=
al-align: baseline; color: rgb(136, 136, 136);"><div style=3D"margin: 0px; =
padding: 0px; border: 0px; vertical-align: baseline;"></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1=
px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddin=
g-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000" style=3D"margin: 0p=
x; padding: 0px; border: 0px; vertical-align: baseline;">I think that this =
is a quite different feature, IIUC, it is independent of how the parameters=
have been defaulted.<br><blockquote type=3D"cite"><div dir=3D"ltr" style=
=3D"margin: 0px; padding: 0px; border: 0px; vertical-align: baseline;"><div=
style=3D"margin: 0px; padding: 0px; border: 0px; vertical-align: baseline;=
"><br></div><div style=3D"margin: 0px; padding: 0px; border: 0px; vertical-=
align: baseline;"><b>If there is no fallback specification</b>, the default=
-ctor of the parameter type is called (in case it's a variable being initia=
lized).</div><div style=3D"margin: 0px; padding: 0px; border: 0px; vertical=
-align: baseline;">If it's a type, a compile-time-error is thrown, or the t=
ype defaults to int (which is what C suggests ;-)</div><br></div></blockquo=
te><br>I don't think you need this also. The caller either shoud specify th=
e he wants a explicit default constructor using explicit {} or the fall-bac=
k value.</div></blockquote></div></div></div></div></div></div></blockquote=
><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><div class=3D"G3J0AAD-gd-a"><div tabindex=3D"=
0" class=3D"G3J0AAD-nb-P"><div style=3D"overflow: auto;"><div dir=3D"ltr"><=
div class=3D"G3J0AAD-xb-b" style=3D"margin: 0px; padding: 0px; border: 0px;=
vertical-align: baseline; color: rgb(136, 136, 136);"><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; b=
order-left-color: rgb(204, 204, 204); border-left-style: solid; padding-lef=
t: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000" style=3D"margin: 0px; pa=
dding: 0px; border: 0px; vertical-align: baseline;"></div></blockquote></di=
v></div></div></div></div></div></blockquote><div> The improvement her=
e is, that the compiler takes the value that is being considered the 'defau=
lt' value by the library developer at this place;</div><div> The calle=
r doesn't have to worry.</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_519_1683981752.1428650603486--
------=_Part_518_587676405.1428650603486--
.
Author: Zijie He <hzj_jie@hotmail.com>
Date: Fri, 10 Apr 2015 07:40:09 -0700 (PDT)
Raw View
------=_Part_1229_34032467.1428676809746
Content-Type: multipart/alternative;
boundary="----=_Part_1230_753022767.1428676809746"
------=_Part_1230_753022767.1428676809746
Content-Type: text/plain; charset=UTF-8
Does this work for you?
#include <iostream>
#include <memory>
using namespace std;
template <typename T, typename P = decltype(shared_ptr<T>())>
void f(P p = P())
{
if (p.get() != nullptr)
cout << *p << endl;
else
cout << "null" << endl;
}
int main()
{
f<int>();
f<const char*>(make_shared<const char*>("abc"));
}
On Friday, April 10, 2015 at 3:23:23 PM UTC+8, Jakob Riedle wrote:
>
>
>
> Am Freitag, 10. April 2015 08:22:34 UTC+2 schrieb Vicente J. Botet Escriba:
>
> We could also consider "Let *explicit {expr}* Be Explicit Constructor".
>
>
> If I rethink this, actually, we *don't have to allow 'default' to use
> explicit default constructors*.
> I think, there are only extremely rare cases out there, where the
> default-ctor has been made explicit,
> because making ctors explicit is mostly for the sake of *unwanted
> implicit conversion*.
>
> The default ctor doesn't do conversions, so you will only stumble on
> explicit default-ctors rarely.
> For those cases, it is ok to write out the full typename, for whatever
> reason the class author wanted that.
>
>>
>
>> I think that this is a quite different feature, IIUC, it is independent
>>> of how the parameters have been defaulted.
>>>
>>>
>>> *If there is no fallback specification*, the default-ctor of the
>>> parameter type is called (in case it's a variable being initialized).
>>> If it's a type, a compile-time-error is thrown, or the type defaults to
>>> int (which is what C suggests ;-)
>>>
>>>
>>> I don't think you need this also. The caller either shoud specify the he
>>> wants a explicit default constructor using explicit {} or the fall-back
>>> value.
>>>
>>
>
>> The improvement here is, that the compiler takes the value that is being
> considered the 'default' value by the library developer at this place;
> The caller doesn't have to worry.
>
--
---
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_1230_753022767.1428676809746
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Does this work for you?<div><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint"><=
font color=3D"#660066"><br></font></div><div class=3D"subprettyprint"><font=
color=3D"#660066">#include <iostream></font></div><div class=3D"subp=
rettyprint"><font color=3D"#660066">#include <memory></font></div><di=
v class=3D"subprettyprint"><font color=3D"#660066">using namespace std;</fo=
nt></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></font><=
/div><div class=3D"subprettyprint"><font color=3D"#660066">template <typ=
ename T, typename P =3D decltype(shared_ptr<T>())></font></div><di=
v class=3D"subprettyprint"><font color=3D"#660066">void f(P p =3D P())</fon=
t></div><div class=3D"subprettyprint"><font color=3D"#660066">{</font></div=
><div class=3D"subprettyprint"><font color=3D"#660066"> if (p.=
get() !=3D nullptr)</font></div><div class=3D"subprettyprint"><font color=
=3D"#660066"> cout << *p << endl;</f=
ont></div><div class=3D"subprettyprint"><font color=3D"#660066"> &nbs=
p; else</font></div><div class=3D"subprettyprint"><font color=3D"#660066">&=
nbsp; cout << "null" << endl;</font></div>=
<div class=3D"subprettyprint"><font color=3D"#660066">}</font></div><div cl=
ass=3D"subprettyprint"><font color=3D"#660066"><br></font></div><div class=
=3D"subprettyprint"><font color=3D"#660066">int main()</font></div><div cla=
ss=3D"subprettyprint"><font color=3D"#660066">{</font></div><div class=3D"s=
ubprettyprint"><font color=3D"#660066"> f<int>();</font>=
</div><div class=3D"subprettyprint"><font color=3D"#660066"> f=
<const char*>(make_shared<const char*>("abc"));</font></div><di=
v class=3D"subprettyprint"><font color=3D"#660066">}</font></div></div></di=
v></code></div><br></div><div><br><br>On Friday, April 10, 2015 at 3:23:23 =
PM UTC+8, Jakob Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br><br>Am Freitag, 10. April 2015 08:22:34 UTC+2 schrieb V=
icente J. Botet Escriba:<div><br></div><div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We could also =
consider "Let <b>explicit {expr}</b> Be Explicit Constructor".</b=
lockquote><div><br></div><div>If I rethink this, actually, we <b>don't have=
to allow 'default' to use explicit default constructors</b>.</div><div>I t=
hink, there are only extremely rare cases out there, where the default-ctor=
has been made explicit,</div><div>because making ctors explicit is mostly =
for the sake of <i>unwanted implicit conversion</i>.</div><div><br></div><d=
iv>The default ctor doesn't do conversions, so you will only stumble on exp=
licit default-ctors rarely.</div><div>For those cases, it is ok to write ou=
t the full typename, for whatever reason the class author wanted that.</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"></div></blockquote><div> &=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF"=
text=3D"#000000"><div><div><div style=3D"overflow:auto"><div dir=3D"ltr"><=
div style=3D"margin:0px;padding:0px;border:0px;vertical-align:baseline;colo=
r:rgb(136,136,136)"><div style=3D"margin:0px;padding:0px;border:0px;vertica=
l-align:baseline"></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#=
000000" style=3D"margin:0px;padding:0px;border:0px;vertical-align:baseline"=
>I think that this is a quite different feature, IIUC, it is independent of=
how the parameters have been defaulted.<br><blockquote type=3D"cite"><div =
dir=3D"ltr" style=3D"margin:0px;padding:0px;border:0px;vertical-align:basel=
ine"><div style=3D"margin:0px;padding:0px;border:0px;vertical-align:baselin=
e"><br></div><div style=3D"margin:0px;padding:0px;border:0px;vertical-align=
:baseline"><b>If there is no fallback specification</b>, the default-ctor o=
f the parameter type is called (in case it's a variable being initialized).=
</div><div style=3D"margin:0px;padding:0px;border:0px;vertical-align:baseli=
ne">If it's a type, a compile-time-error is thrown, or the type defaults to=
int (which is what C suggests ;-)</div><br></div></blockquote><br>I don't =
think you need this also. The caller either shoud specify the he wants a ex=
plicit default constructor using explicit {} or the fall-back value.</div><=
/blockquote></div></div></div></div></div></div></blockquote><div> </d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D=
"#000000"><div><div><div style=3D"overflow:auto"><div dir=3D"ltr"><div styl=
e=3D"margin:0px;padding:0px;border:0px;vertical-align:baseline;color:rgb(13=
6,136,136)"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000" styl=
e=3D"margin:0px;padding:0px;border:0px;vertical-align:baseline"></div></blo=
ckquote></div></div></div></div></div></div></blockquote><div> The imp=
rovement here is, that the compiler takes the value that is being considere=
d the 'default' value by the library developer at this place;</div><div>&nb=
sp;The caller doesn't have to worry.</div></div></div></blockquote></div></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1230_753022767.1428676809746--
------=_Part_1229_34032467.1428676809746--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Fri, 10 Apr 2015 08:07:09 -0700 (PDT)
Raw View
------=_Part_127_497488559.1428678429939
Content-Type: multipart/alternative;
boundary="----=_Part_128_1957512513.1428678429940"
------=_Part_128_1957512513.1428678429940
Content-Type: text/plain; charset=UTF-8
Am Freitag, 10. April 2015 16:40:09 UTC+2 schrieb Zijie He:
>
> Does this work for you?
>
> #include <iostream>
> #include <memory>
> using namespace std;
>
> template <typename T, typename P = decltype(shared_ptr<T>())>
> void f(P p = P())
> {
> if (p.get() != nullptr)
> cout << *p << endl;
> else
> cout << "null" << endl;
> }
>
> int main()
> {
> f<int>();
> f<const char*>(make_shared<const char*>("abc"));
> }
>
>
Why shouldn't it?
*Note:*
I would not construct a shared_ptr from a literal, since you would not do
"delete ((const char*)"abc") either, would you?
Please correct me, if I'm wrong, or if that is not relevant for that
example.
It should work, yes.
*What do you want to point out?, *please express yourself more clearly.
--
---
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_128_1957512513.1428678429940
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Am Freitag, 10. April 2015 16:40:09 UTC+2 schrieb Zijie He=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Does this wo=
rk for you?<div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:b=
reak-word;background-color:rgb(250,250,250)"><code><div><div><div><font col=
or=3D"#660066"><br></font></div><div><font color=3D"#660066">#include <i=
ostream></font></div><div><font color=3D"#660066">#include <memory>=
;</font></div><div><font color=3D"#660066">using namespace std;</font></div=
><div><font color=3D"#660066"><br></font></div><div><font color=3D"#660066"=
>template <typename T, typename P =3D decltype(shared_ptr<T>())>=
;</font></div><div><font color=3D"#660066">void f(P p =3D P())</font></div>=
<div><font color=3D"#660066">{</font></div><div><font color=3D"#660066">&nb=
sp; if (p.get() !=3D nullptr)</font></div><div><font color=3D"#66006=
6"> cout << *p << endl;</font></div>=
<div><font color=3D"#660066"> else</font></div><div><font colo=
r=3D"#660066"> cout << "null" << end=
l;</font></div><div><font color=3D"#660066">}</font></div><div><font color=
=3D"#660066"><br></font></div><div><font color=3D"#660066">int main()</font=
></div><div><font color=3D"#660066">{</font></div><div><font color=3D"#6600=
66"> f<int>();</font></div><div><font color=3D"#660066">=
f<const char*>(make_shared<const char*>("abc"));<=
/font></div><div><font color=3D"#660066">}</font></div></div></div></code><=
/div></div><br></div></blockquote><div><br></div><div>Why shouldn't it?</di=
v><div><br></div><div><u>Note:</u></div><div>I would not construct a shared=
_ptr from a literal, since you would not do "delete ((const char*)"abc") ei=
ther, would you?</div><div>Please correct me, if I'm wrong, or if that is n=
ot relevant for that example.</div><div><br></div><div>It should work, yes.=
</div><div><b>What do you want to point out?, </b>please express yourself m=
ore clearly.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_128_1957512513.1428678429940--
------=_Part_127_497488559.1428678429939--
.
Author: Zijie He <hzj_jie@hotmail.com>
Date: Fri, 10 Apr 2015 08:30:58 -0700 (PDT)
Raw View
------=_Part_1259_2025060950.1428679858347
Content-Type: multipart/alternative;
boundary="----=_Part_1260_1878548994.1428679858347"
------=_Part_1260_1878548994.1428679858347
Content-Type: text/plain; charset=UTF-8
I believe the problem you want to resolve is, you need to write the type
weak_ptr<ClassName> in your case twice.
And make_shared<const char*> creates a pointer of const char*, so it would
like to delete ((const char**));, my fault to provide a bad usage example.
f<string>(make_shared<string>("abc"));
would be better.
On Friday, April 10, 2015 at 11:07:10 PM UTC+8, Jakob Riedle wrote:
>
> Am Freitag, 10. April 2015 16:40:09 UTC+2 schrieb Zijie He:
>>
>> Does this work for you?
>>
>> #include <iostream>
>> #include <memory>
>> using namespace std;
>>
>> template <typename T, typename P = decltype(shared_ptr<T>())>
>> void f(P p = P())
>> {
>> if (p.get() != nullptr)
>> cout << *p << endl;
>> else
>> cout << "null" << endl;
>> }
>>
>> int main()
>> {
>> f<int>();
>> f<const char*>(make_shared<const char*>("abc"));
>> }
>>
>>
> Why shouldn't it?
>
> *Note:*
> I would not construct a shared_ptr from a literal, since you would not do
> "delete ((const char*)"abc") either, would you?
> Please correct me, if I'm wrong, or if that is not relevant for that
> example.
>
> It should work, yes.
> *What do you want to point out?, *please express yourself more clearly.
>
--
---
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_1260_1878548994.1428679858347
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I believe the problem you want to resolve is, you need to =
write the type weak_ptr<ClassName> in your case twice.<div>And make_s=
hared<const char*> creates a pointer of const char*, so it would like=
to delete ((const char**));, my fault to provide a bad usage example.</div=
><div>f<string>(make_shared<string>("abc"));</div><div>would be=
better.<br><div><br>On Friday, April 10, 2015 at 11:07:10 PM UTC+8, Jakob =
Riedle 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">=
Am Freitag, 10. April 2015 16:40:09 UTC+2 schrieb Zijie He:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">Does this work for you?<div><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><div><div><font color=3D"#660066"><br></f=
ont></div><div><font color=3D"#660066">#include <iostream></font></di=
v><div><font color=3D"#660066">#include <memory></font></div><div><fo=
nt color=3D"#660066">using namespace std;</font></div><div><font color=3D"#=
660066"><br></font></div><div><font color=3D"#660066">template <typename=
T, typename P =3D decltype(shared_ptr<T>())></font></div><div><fo=
nt color=3D"#660066">void f(P p =3D P())</font></div><div><font color=3D"#6=
60066">{</font></div><div><font color=3D"#660066"> if (p.get()=
!=3D nullptr)</font></div><div><font color=3D"#660066">  =
; cout << *p << endl;</font></div><div><font color=3D"#6=
60066"> else</font></div><div><font color=3D"#660066"> &=
nbsp; cout << "null" << endl;</font></div><div><f=
ont color=3D"#660066">}</font></div><div><font color=3D"#660066"><br></font=
></div><div><font color=3D"#660066">int main()</font></div><div><font color=
=3D"#660066">{</font></div><div><font color=3D"#660066"> f<=
int>();</font></div><div><font color=3D"#660066"> f<cons=
t char*>(make_shared<const char*>("abc"));</font></div><div><font =
color=3D"#660066">}</font></div></div></div></code></div></div><br></div></=
blockquote><div><br></div><div>Why shouldn't it?</div><div><br></div><div><=
u>Note:</u></div><div>I would not construct a shared_ptr from a literal, si=
nce you would not do "delete ((const char*)"abc") either, would you?</div><=
div>Please correct me, if I'm wrong, or if that is not relevant for that ex=
ample.</div><div><br></div><div>It should work, yes.</div><div><b>What do y=
ou want to point out?, </b>please express yourself more clearly.</div></div=
></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1260_1878548994.1428679858347--
------=_Part_1259_2025060950.1428679858347--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 10 Apr 2015 11:46:31 -0400
Raw View
On 2015-04-10 01:30, Vicente J. Botet Escriba wrote:
> I'm not a language expert, but I'm getting
>
> struct E {
> explicit E() {}
> };
> struct I {
> I() {}
> };
>
> void f(I p = {}) {}
> //void f(E p = {}); // compile error
Interesting... besides that I wasn't aware that zero-argument ctors
could be explicit, I don't get this with gcc-c++-4.8.3-7.fc20.x86_64.
What compiler are you using?
Presumably one of these has a bug; hopefully one of the more language
knowledgeable folks here can say which?
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 10 Apr 2015 19:24:40 +0200
Raw View
Le 10/04/15 17:46, Matthew Woehlke a =C3=A9crit :
> On 2015-04-10 01:30, Vicente J. Botet Escriba wrote:
>> I'm not a language expert, but I'm getting
>>
>> struct E {
>> explicit E() {}
>> };
>> struct I {
>> I() {}
>> };
>>
>> void f(I p =3D {}) {}
>> //void f(E p =3D {}); // compile error
> Interesting... besides that I wasn't aware that zero-argument ctors
> could be explicit,
Neither me until I tried it. But maybe this is not correct code.
> I don't get this with gcc-c++-4.8.3-7.fc20.x86_64.
> What compiler are you using?
gcc-4.9.1 -std=3Dc++1y
clang-3.5 -std=3Dc++1y
> Presumably one of these has a bug; hopefully one of the more language
> knowledgeable folks here can say which?
>
Vicente
--=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/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 10 Apr 2015 19:29:21 +0200
Raw View
This is a multi-part message in MIME format.
--------------000207000108040502020104
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 10/04/15 08:56, Jakob Riedle a =C3=A9crit :
>
> We could also consider "Let *explicit {expr}* Be Explicit
> Constructor".
>
>
> But insn't that exactly, what N4131 wanted to prohibit?
Humm, not exactly, 4131 proposal was {} , I'm proposing explcit {},=20
which intent is quite explicit.
>
> Note that the following works already
>
> struct explicit_d {};
>
> struct E {
> explicit E() {}
> E(explicit_d) {}
> };
>
> void f(E p =3D explicit_d{}); // OK
> //void f(E p =3D {}); // compile error
>
>
> That's one of the reasons to write a proposal.
Maybe.
>
> I think that this is a quite different feature, IIUC, it is
> independent of how the parameters have been defaulted.
>>
>> *If there is no fallback specification*, the default-ctor of the
>> parameter type is called (in case it's a variable being initialized)=
..
>> If it's a type, a compile-time-error is thrown, or the type
>> defaults to int (which is what C suggests ;-)
>>
>
> I don't think you need this also. The caller either shoud specify
> the he wants a explicit default constructor using explicit {} or
> the fall-back value.
>
>
> The cool thing about it is, that the compiler takes the value that is=20
> being considered the 'default' value by the library developer at this=20
> place;
> The caller doesn't have to worry.
>
IMHO, you are mixing here the default constructor and the parameter=20
default value.
Vicente
--=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/.
--------------000207000108040502020104
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 10/04/15 08:56, Jakob Riedle a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:5bba1def-9dee-4abd-9038-dc66a3f2b913@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px
0.8ex; border-left-width: 1px; border-left-color: rgb(204,
204, 204); border-left-style: solid; padding-left: 1ex;">We
could also consider "Let=C2=A0<b>explicit {expr}</b>=C2=A0Be Expl=
icit
Constructor".</blockquote>
<div><br>
</div>
<div>But insn't that exactly, what N4131 wanted to prohibit?</div>
</div>
</blockquote>
Humm, not exactly, 4131 proposal was {} , I'm proposing explcit {},
which intent is quite explicit.<br>
<blockquote
cite=3D"mid:5bba1def-9dee-4abd-9038-dc66a3f2b913@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> Note that the followin=
g
works already<br>
<br>
struct explicit_d {};<br>
<br>
struct E {<br>
=C2=A0 explicit E() {}<br>
=C2=A0 E(explicit_d) {}<br>
};<br>
<br>
void f(E p =3D explicit_d{}); // OK<br>
//void f(E p =3D {}); // compile error<br>
</div>
</blockquote>
<div><br>
</div>
<div>That's one of the reasons to write a proposal.</div>
</div>
</blockquote>
Maybe. <br>
<blockquote
cite=3D"mid:5bba1def-9dee-4abd-9038-dc66a3f2b913@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I think that this is a
quite different feature, IIUC, it is independent of how the
parameters have been defaulted.<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div><b>If there is no fallback specification</b>, the
default-ctor of the parameter type is called (in case
it's a variable being initialized).</div>
<div>If it's a type, a compile-time-error is thrown, or
the type defaults to int (which is what C suggests ;-)</d=
iv>
<br>
</div>
</blockquote>
<br>
I don't think you need this also. The caller either shoud
specify the he wants a explicit default constructor using
explicit {} or the fall-back value.<br>
</div>
</blockquote>
<div><br>
</div>
<div>The cool thing about it is, that the compiler takes the
value that is being considered the 'default' value by the
library developer at this place;</div>
<div>The caller doesn't have to worry.</div>
</div>
<br>
</blockquote>
IMHO, you are mixing here the default constructor and the parameter
default value.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000207000108040502020104--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sat, 11 Apr 2015 12:45:03 -0700 (PDT)
Raw View
------=_Part_1918_1756627739.1428781503702
Content-Type: multipart/alternative;
boundary="----=_Part_1919_37230417.1428781503702"
------=_Part_1919_37230417.1428781503702
Content-Type: text/plain; charset=UTF-8
Am Freitag, 10. April 2015 19:29:23 UTC+2 schrieb Vicente J. Botet Escriba:
>
> Humm, not exactly, 4131 proposal was {} , I'm proposing explcit {},
> which intent is quite explicit.
>
I mean, its still kinda implicit, since the name of the type is not being
mentioned. But anyway the programmer has to
think about what he's doing, so accidents are not likely to happen. I guess
thats a good idea.
> IMHO, you are mixing here the default constructor and the parameter
> default value.
>
> Vicente
>
I though about it for some while and you might be right. Especially if you
consider how likely that mixture
is going to get into standard.
So it's probably best to make two proposals, one proposing "explicit{}" and
one "default".
If I get you right, default should be restricted to parameter
initialization.
But to get into detail:
Do you think only parameters having a fallback value associated can be
specified with 'default', or both?
If you allow it for both types of parameters, 'default' already initializes
non-defaulted variables, which might not be too good.
Then it would be better to allow only optional parameters, which is what i
like best.
What do you think?
Jakob
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1919_37230417.1428781503702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Freitag, 10. April 2015 19:29:23 UTC+2 schrieb =
Vicente J. Botet Escriba:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Humm, not exactly, 4131 proposal was {} , I'm proposing explcit {}=
,
which intent is quite explicit.</div></div></blockquote><div><br></div>=
<div>I mean, its still kinda implicit, since the name of the type is not be=
ing mentioned. But anyway the programmer has to</div><div>think about what =
he's doing, so accidents are not likely to happen. I guess thats a good ide=
a.</div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
bgcolor=3D"#FFFFFF" text=3D"#000000">
IMHO, you are mixing here the default constructor and the parameter
default value.<br>
<br>
Vicente<br></div></blockquote><div><br></div><div>I though about it for=
some while and you might be right. Especially if you consider how likely t=
hat mixture</div><div>is going to get into standard.</div><div>So it's prob=
ably best to make two proposals, one proposing "explicit{}" and one "defaul=
t".</div><div><br></div><div>If I get you right, default should be restrict=
ed to parameter initialization.<br></div><div>But to get into detail:</div>=
<div>Do you think only parameters having a fallback value associated can be=
specified with 'default', or both?</div><div>If you allow it for both type=
s of parameters, 'default' already initializes non-defaulted variables, whi=
ch might not be too good.</div><div>Then it would be better to allow only o=
ptional parameters, which is what i like best.</div><div>What do you think?=
</div><div><br></div><div>Jakob</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1919_37230417.1428781503702--
------=_Part_1918_1756627739.1428781503702--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 12 Apr 2015 11:37:57 +0200
Raw View
This is a multi-part message in MIME format.
--------------060800000109000704090209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/04/15 21:45, Jakob Riedle a =C3=A9crit :
>
>
> Am Freitag, 10. April 2015 19:29:23 UTC+2 schrieb Vicente J. Botet=20
> Escriba:
>
> Humm, not exactly, 4131 proposal was {} , I'm proposing explcit
> {}, which intent is quite explicit.
>
>
> I mean, its still kinda implicit, since the name of the type is not=20
> being mentioned. But anyway the programmer has to
> think about what he's doing, so accidents are not likely to happen. I=20
> guess thats a good idea.
Yes, while the intent is to explicit construct a type from the=20
expression inside {}, it is not as explicit as when the type name is=20
given of course.
>
> IMHO, you are mixing here the default constructor and the
> parameter default value.
>
>
> I though about it for some while and you might be right. Especially if=20
> you consider how likely that mixture
> is going to get into standard.
> So it's probably best to make two proposals, one proposing=20
> "explicit{}" and one "default".
>
Well, as explicit default constructor are not used too much, I don't=20
think it is worth a proposal for "explicit {}". However I'm all for a=20
proposal for "explicit {expr}", but this is another history. The main=20
issue is that this change the way overload resolution is done. However,=20
restricting this expression to default parameters and return types would=20
be easier to implement.
> If I get you right, default should be restricted to parameter=20
> initialization.
If you mean at the call site, yes.
> But to get into detail:
> Do you think only parameters having a fallback value associated can be=20
> specified with 'default', or both?
> If you allow it for both types of parameters, 'default' already=20
> initializes non-defaulted variables, which might not be too good.
> Then it would be better to allow only optional parameters, which is=20
> what i like best.
> What do you think?
>
>
I find useful a way to mean the parameter default value (no default=20
construction) at this position. Maybe the auto keyword could play also=20
the same role. I'm sure someone has already written something about this=20
feature, but I have no links.
Vicente
--=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/.
--------------060800000109000704090209
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/04/15 21:45, Jakob Riedle a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:b09f717c-b59e-4717-a4fe-cfb68ede607a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
Am Freitag, 10. April 2015 19:29:23 UTC+2 schrieb Vicente J.
Botet Escriba:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Humm, not exactly, 4131 proposal was {} , I'm proposing
explcit {}, which intent is quite explicit.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I mean, its still kinda implicit, since the name of the
type is not being mentioned. But anyway the programmer has to</di=
v>
<div>think about what he's doing, so accidents are not likely to
happen. I guess thats a good idea.</div>
</div>
</blockquote>
Yes, while the intent is to explicit construct a type from the
expression inside {}, it is not as explicit as when the type name is
given of course. <br>
<blockquote
cite=3D"mid:b09f717c-b59e-4717-a4fe-cfb68ede607a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> IMHO, you are mixing
here the default constructor and the parameter default
value.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>I though about it for some while and you might be right.
Especially if you consider how likely that mixture</div>
<div>is going to get into standard.</div>
<div>So it's probably best to make two proposals, one proposing
"explicit{}" and one "default".</div>
<div><br>
</div>
</div>
</blockquote>
Well, as explicit default constructor are not used too much, I don't
think it is worth a proposal for "explicit {}". However I'm all for
a proposal for "explicit {expr}", but this is another history. The
main issue is that this change the way overload resolution is done.
However, restricting this expression to default parameters and
return types would be easier to implement.<br>
<br>
<blockquote
cite=3D"mid:b09f717c-b59e-4717-a4fe-cfb68ede607a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>If I get you right, default should be restricted to
parameter initialization.<br>
</div>
</div>
</blockquote>
If you mean at the call site, yes.<br>
<blockquote
cite=3D"mid:b09f717c-b59e-4717-a4fe-cfb68ede607a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>But to get into detail:</div>
<div>Do you think only parameters having a fallback value
associated can be specified with 'default', or both?</div>
<div>If you allow it for both types of parameters, 'default'
already initializes non-defaulted variables, which might not
be too good.</div>
<div>Then it would be better to allow only optional parameters,
which is what i like best.</div>
<div>What do you think?</div>
<div><br>
</div>
<br>
</div>
</blockquote>
I find useful a way to mean the parameter default value (no default
construction) at this position. Maybe the auto=C2=A0 keyword could play
also the same role. I'm sure someone has already written something
about this feature, but I have no links.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------060800000109000704090209--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sun, 12 Apr 2015 03:30:37 -0700 (PDT)
Raw View
------=_Part_2827_1310430084.1428834637051
Content-Type: multipart/alternative;
boundary="----=_Part_2828_1953621803.1428834637051"
------=_Part_2828_1953621803.1428834637051
Content-Type: text/plain; charset=UTF-8
Am Sonntag, 12. April 2015 11:38:00 UTC+2 schrieb Vicente J. Botet Escriba:
>
> However, restricting this expression to default parameters and return
>> types would be easier to implement.
>>
>
> If I get you right, default should be restricted to parameter
> initialization.
>
> If you mean at the call site, yes.
>
Why would you allow it for return types?
"{}" serves just fine, doesn't i?
I find useful a way to mean the parameter default value (no default
> construction) at this position. Maybe the auto keyword could play also the
> same role.
>
I find auto to be misleading at this point, because it usually makes the
compiler specify the type. But in this case it's the function developer
himself to specify the default value.
I also like, how 'default' speaks for itself. I also think auto should not
be reused at this completely new use case.
Best,
Jakob
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2828_1953621803.1428834637051
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Am Sonntag, 12. April 2015 11:38:00 UTC+2 schrieb =
Vicente J. Botet Escriba:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite"><div dir=3D"ltr"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><span style=3D"f=
ont-size: 13px;">However, restricting this expression to default parameters=
and
return types would be easier to implement.</span><br></div></div></bloc=
kquote></div></blockquote>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>If I get you right, default should be restricted to
parameter initialization.<br>
</div>
</div>
</blockquote>
If you mean at the call site, yes.<br></div></blockquote><div><br></div=
><div>Why would you allow it for return types?</div><div><span style=3D"fon=
t-size: 13px;"> "{}" serves just fine, doesn't i? </span></div><d=
iv><span style=3D"font-size: 13px;"><br></span></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
I find useful a way to mean the parameter default value (no default
construction) at this position. Maybe the auto keyword could play
also the same role.<br></div></blockquote><div><br></div><div>I find au=
to to be misleading at this point, because it usually makes the compiler sp=
ecify the type. But in this case it's the function developer himself to spe=
cify the default value.</div><div>I also like, how 'default' speaks for its=
elf. I also think auto should not be reused at this completely new use case=
..</div><div><br></div><div>Best,</div><div>Jakob</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2828_1953621803.1428834637051--
------=_Part_2827_1310430084.1428834637051--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 12 Apr 2015 13:01:37 +0200
Raw View
This is a multi-part message in MIME format.
--------------070400060908030808050705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 12/04/15 12:30, Jakob Riedle a =C3=A9crit :
>
>
> Am Sonntag, 12. April 2015 11:38:00 UTC+2 schrieb Vicente J. Botet=20
> Escriba:
>
>> However, restricting this expression to default parameters
>> and return types would be easier to implement.
>>
>
>> If I get you right, default should be restricted to parameter
>> initialization.
> If you mean at the call site, yes.
>
>
> Why would you allow it for return types?
> "{}" serves just fine, doesn't i?
>
>
Maybe I was not clear enough. If you have the two new expressions as=20
you(I) suggested: default and explicit {expre}, default could be used=20
only at the call site. explicit {expr} could be used as default=20
parameter value or an assignment expression or in a return statement.=20
Using it on at the call site of a function introduces complexity type=20
deduction system due to overload resolution.
BTW, using default on the call site introduces the same kind of problems=20
as using explicit {expr} :(
{} or {expr} work if the class has a implicit constructors from these=20
expressions. You need something else to tell the compiler that you want=20
to be able to use them explicit constructors also.
Vicente
--=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/.
--------------070400060908030808050705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 12/04/15 12:30, Jakob Riedle a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:1130b7f8-6e46-4dd7-a429-2e8a4d20ed28@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
Am Sonntag, 12. April 2015 11:38:00 UTC+2 schrieb Vicente J.
Botet Escriba:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div><span style=3D"font-size: 13px;">However,
restricting this expression to default
parameters and return types would be easier to
implement.</span><br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>If I get you right, default should be restricted to
parameter initialization.<br>
</div>
</div>
</blockquote>
If you mean at the call site, yes.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Why would you allow it for return types?</div>
<div><span style=3D"font-size: 13px;">=C2=A0"{}" serves just fine,
doesn't i?=C2=A0</span></div>
<div><span style=3D"font-size: 13px;"><br>
</span></div>
<br>
</div>
</blockquote>
Maybe I was not clear enough. If you have the two new expressions as
you(I) suggested: default and explicit {expre}, default could be
used only at the call site. explicit {expr} could be used as default
parameter value or an assignment expression or in a return
statement. Using it on at the call site of a function introduces
complexity type deduction system due to overload resolution. <br>
<br>
BTW, using default on the call site introduces the same kind of
problems as using explicit {expr} :(<br>
<br>
{} or {expr} work if the class has a implicit constructors from
these expressions. You need something else to tell the compiler that
you want to be able to use them explicit constructors also.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070400060908030808050705--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Sun, 12 Apr 2015 10:58:33 -0700 (PDT)
Raw View
------=_Part_310_742841661.1428861513792
Content-Type: text/plain; charset=UTF-8
> BTW, using default on the call site
> introduces the same kind of problems as > using explicit {expr} :(
I intended to allow referencing the fallback value through passing 'default'.
That is the specified fallback expression initializes the parameter, not 'default'.
So proposing 'default' at function calls is independent of variable initialization n in general.
Jakob
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_310_742841661.1428861513792--
.
Author: Jakob Riedle <jakob.riedle@gmail.com>
Date: Wed, 15 Apr 2015 08:06:36 -0700 (PDT)
Raw View
------=_Part_169_1977916043.1429110396366
Content-Type: multipart/alternative;
boundary="----=_Part_170_1935562788.1429110396366"
------=_Part_170_1935562788.1429110396366
Content-Type: text/plain; charset=UTF-8
What do you think Vicente?
--
---
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_170_1935562788.1429110396366
Content-Type: text/html; charset=UTF-8
<div dir="ltr">What do you think Vicente?</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_170_1935562788.1429110396366--
------=_Part_169_1977916043.1429110396366--
.