Topic: Proposal - Returning a nullopt from a function
Author: RobertBadea <badea.robert92@gmail.com>
Date: Sun, 11 Nov 2018 22:18:59 -0800 (PST)
Raw View
------=_Part_1717_388331647.1542003539154
Content-Type: multipart/alternative;
boundary="----=_Part_1718_135804263.1542003539155"
------=_Part_1718_135804263.1542003539155
Content-Type: text/plain; charset="UTF-8"
Hello everyone,
Is there any proposal floating regarding returning an uninitialized
optional?
I'm referring to the following functions:
std::optional<int> get1()
{
auto opt = make_optional<int>(4);
if (opt.has_value()) return opt;
return std::nullopt;
}
auto get2()
{
auto opt = make_optional<int>(4);
if (opt.has_value()) return opt;
return std::nullopt;
}
std::optional<int> get3()
{
auto opt = make_optional<int>(4);
return (opt.has_value() ? opt.value() : std::nullopt;
}
The first one compiles, but the second one does not (auto cannot simply
deduce the type of nullopt, as it's basically an {} )
The third one is also something that I'd expect to be able to do, but the
compiler does not allow unary return of such kind.
All the best,
Robert
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/68301482-d370-4eef-9670-490724fde114%40isocpp.org.
------=_Part_1718_135804263.1542003539155
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everyone,=C2=A0<div>Is there any proposal floating r=
egarding returning an uninitialized optional?</div><div><br></div><div>I=
9;m referring to the following functions:</div><div><br></div><div><div>std=
::optional<int> get1()</div><div>{</div><div><span style=3D"white-spa=
ce:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><span s=
tyle=3D"white-space:pre"> </span>if (opt.has_value()) return opt;</div><div=
><span style=3D"white-space:pre"> </span>return std::nullopt;</div><div>}</=
div><div><br></div><div>auto get2()</div><div>{</div><div><span style=3D"wh=
ite-space:pre"> </span>auto opt =3D make_optional<int>(4);</div><div>=
<span style=3D"white-space:pre"> </span>if (opt.has_value()) return opt;</d=
iv><div><span style=3D"white-space:pre"> </span>return std::nullopt;</div><=
div>}</div><div><br></div><div>std::optional<int> get3()</div><div>{<=
/div><div><span style=3D"white-space:pre"> </span>auto opt =3D make_optiona=
l<int>(4);</div><div><span style=3D"white-space:pre"> </span>return (=
opt.has_value() ? opt.value() : std::nullopt;</div><div>}</div><div><br></d=
iv></div><div><br></div><div>The first one compiles, but the second one doe=
s not (auto cannot simply deduce the type of nullopt, as it's basically=
an {} )</div><div>The third one is also something that I'd expect to b=
e able to do, but the compiler does not allow unary return of such kind.</d=
iv><div><br></div><div>All the best,</div><div>Robert</div><div><br></div><=
/div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/68301482-d370-4eef-9670-490724fde114%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/68301482-d370-4eef-9670-490724fde114=
%40isocpp.org</a>.<br />
------=_Part_1718_135804263.1542003539155--
------=_Part_1717_388331647.1542003539154--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 12 Nov 2018 00:18:59 -0800
Raw View
On Sunday, 11 November 2018 22:18:59 PST RobertBadea wrote:
> The first one compiles, but the second one does not (auto cannot simply
> deduce the type of nullopt, as it's basically an {} )
That's an incorrect summary of what's happening. The compiler *can* deduce the
type of std::nullopt and that's exactly the reason why it won't compile: opt
and std::nullopt have different types. You cannot have two return statements
with different types in a function with deduced return type: they must ALL
match exactly.
This will compile:
auto get2()
{
auto opt = make_optional<int>(4);
if (opt.has_value()) return opt;
return decltype(opt)(std::nullopt);
}
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3987762.rjX2lu7Bim%40tjmaciei-mobl1.
.
Author: mihailnajdenov@gmail.com
Date: Mon, 12 Nov 2018 00:21:54 -0800 (PST)
Raw View
------=_Part_1779_91332357.1542010914158
Content-Type: multipart/alternative;
boundary="----=_Part_1780_1324002203.1542010914158"
------=_Part_1780_1324002203.1542010914158
Content-Type: text/plain; charset="UTF-8"
I think you have the wrong expectations.
The problem is that nullopt is completely unrelated type to std::optional<>
In the second example you are trying to return two different types and it
fails
you can "fix" this by
auto get2()
{
auto opt = std::optional(4);
if (opt.has_value()) return opt;
return decltype(opt){};
}
The third example does not work because the ternary op expects also the
same types, but these are different (obviously).
Having defined return type does not help because ternary is evaluated first
and its result is passed to the return type
On Monday, November 12, 2018 at 8:18:59 AM UTC+2, robert badea wrote:
>
> Hello everyone,
> Is there any proposal floating regarding returning an uninitialized
> optional?
>
> I'm referring to the following functions:
>
> std::optional<int> get1()
> {
> auto opt = make_optional<int>(4);
> if (opt.has_value()) return opt;
> return std::nullopt;
> }
>
> auto get2()
> {
> auto opt = make_optional<int>(4);
> if (opt.has_value()) return opt;
> return std::nullopt;
> }
>
> std::optional<int> get3()
> {
> auto opt = make_optional<int>(4);
> return (opt.has_value() ? opt.value() : std::nullopt;
> }
>
>
> The first one compiles, but the second one does not (auto cannot simply
> deduce the type of nullopt, as it's basically an {} )
> The third one is also something that I'd expect to be able to do, but the
> compiler does not allow unary return of such kind.
>
> All the best,
> Robert
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e7f15160-e30f-437f-95d8-7cc504767f55%40isocpp.org.
------=_Part_1780_1324002203.1542010914158
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think you have the wrong expectations.<div><br></div><di=
v>The problem is that nullopt is completely unrelated type to std::optional=
<></div><div><br></div><div>In the second example you are trying to r=
eturn two different types and it fails</div><div><br></div><div>you can &qu=
ot;fix" this by</div><div><br></div><div><div>auto get2()</div><div>{<=
/div><div><span style=3D"white-space:pre"> </span>auto opt =3D std::optiona=
l(4);</div><div><span style=3D"white-space:pre"> </span>if (opt.has_value()=
) return opt;</div><div><span style=3D"white-space:pre"> </span>return decl=
type(opt){};</div><div>}</div></div><div><br></div><div>The third example d=
oes not work because the ternary op expects also the same types, but these =
are different (obviously).</div><div>Having defined return type does not he=
lp because ternary is evaluated first and its result is passed to the retur=
n type</div><div><br></div><div><br></div><div><br>On Monday, November 12, =
2018 at 8:18:59 AM UTC+2, robert badea wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">Hello everyone,=C2=A0<div>Is there any prop=
osal floating regarding returning an uninitialized optional?</div><div><br>=
</div><div>I'm referring to the following functions:</div><div><br></di=
v><div><div>std::optional<int> get1()</div><div>{</div><div><span sty=
le=3D"white-space:pre"> </span>auto opt =3D make_optional<int>(4);</d=
iv><div><span style=3D"white-space:pre"> </span>if (opt.has_value()) return=
opt;</div><div><span style=3D"white-space:pre"> </span>return std::nullopt=
;</div><div>}</div><div><br></div><div>auto get2()</div><div>{</div><div><s=
pan style=3D"white-space:pre"> </span>auto opt =3D make_optional<int>=
(4);</div><div><span style=3D"white-space:pre"> </span>if (opt.has_value())=
return opt;</div><div><span style=3D"white-space:pre"> </span>return std::=
nullopt;</div><div>}</div><div><br></div><div>std::optional<int> get3=
()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =
=3D make_optional<int>(4);</div><div><span style=3D"white-space:pre">=
</span>return (opt.has_value() ? opt.value() : std::nullopt;</div><div>}</=
div><div><br></div></div><div><br></div><div>The first one compiles, but th=
e second one does not (auto cannot simply deduce the type of nullopt, as it=
's basically an {} )</div><div>The third one is also something that I&#=
39;d expect to be able to do, but the compiler does not allow unary return =
of such kind.</div><div><br></div><div>All the best,</div><div>Robert</div>=
<div><br></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e7f15160-e30f-437f-95d8-7cc504767f55%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e7f15160-e30f-437f-95d8-7cc504767f55=
%40isocpp.org</a>.<br />
------=_Part_1780_1324002203.1542010914158--
------=_Part_1779_91332357.1542010914158--
.
Author: Itaj Sherman <itajsherman@gmail.com>
Date: Thu, 15 Nov 2018 16:42:26 -0800 (PST)
Raw View
------=_Part_973_1184418834.1542328946651
Content-Type: multipart/alternative;
boundary="----=_Part_974_1133745266.1542328946651"
------=_Part_974_1133745266.1542328946651
Content-Type: text/plain; charset="UTF-8"
I disagree with the other responds. I actually think you have a point.
nullopt and optional<int> are not totally "unrelated", specifically
std::common_type< nullopt, optional<int> >::type === optional<int>.
Suppose you have a function with several return statements returning type
R1..Rn.
The currently rules of auto return deduction is they all have to be the
same type, and it will be deduced.
But another reasonable option could have been that the deduced return type
will be std::common_type<R...>::type.
itaj
On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
> Hello everyone,
> Is there any proposal floating regarding returning an uninitialized
> optional?
>
> I'm referring to the following functions:
>
> std::optional<int> get1()
> {
> auto opt = make_optional<int>(4);
> if (opt.has_value()) return opt;
> return std::nullopt;
> }
>
> auto get2()
> {
> auto opt = make_optional<int>(4);
> if (opt.has_value()) return opt;
> return std::nullopt;
> }
>
> std::optional<int> get3()
> {
> auto opt = make_optional<int>(4);
> return (opt.has_value() ? opt.value() : std::nullopt;
> }
>
>
> The first one compiles, but the second one does not (auto cannot simply
> deduce the type of nullopt, as it's basically an {} )
> The third one is also something that I'd expect to be able to do, but the
> compiler does not allow unary return of such kind.
>
> All the best,
> Robert
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/894a072f-c1fc-4d6d-a37f-07a81f70a4ea%40isocpp.org.
------=_Part_974_1133745266.1542328946651
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>I disagree with the other responds. I actually think y=
ou have a point.<br><br><div>nullopt and optional<int> are not totall=
y "unrelated", specifically std::common_type< nullopt, optiona=
l<int> >::type =3D=3D=3D optional<int>.</div><div><br></div>=
<div>Suppose you have a function with several return statements returning t=
ype R1..Rn.<br></div><div>The currently rules of auto return deduction is t=
hey all have to be the same type, and it will be deduced.</div><div>But ano=
ther reasonable option could have been that the deduced return type will be=
std::common_type<R...>::type.</div><div><br></div><div>itaj<br></div=
><div><br></div><div>On Monday, 12 November 2018 08:18:59 UTC+2, robert bad=
ea wrote:<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">Hello everyone,=C2=A0<div>Is there any proposal floating regard=
ing returning an uninitialized optional?</div><div><br></div><div>I'm r=
eferring to the following functions:</div><div><br></div><div><div>std::opt=
ional<int> get1()</div><div>{</div><div><span style=3D"white-space:pr=
e"> </span>auto opt =3D make_optional<int>(4);</div><div><span style=
=3D"white-space:pre"> </span>if (opt.has_value()) return opt;</div><div><sp=
an style=3D"white-space:pre"> </span>return std::nullopt;</div><div>}</div>=
<div><br></div><div>auto get2()</div><div>{</div><div><span style=3D"white-=
space:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><spa=
n style=3D"white-space:pre"> </span>if (opt.has_value()) return opt;</div><=
div><span style=3D"white-space:pre"> </span>return std::nullopt;</div><div>=
}</div><div><br></div><div>std::optional<int> get3()</div><div>{</div=
><div><span style=3D"white-space:pre"> </span>auto opt =3D make_optional<=
;int>(4);</div><div><span style=3D"white-space:pre"> </span>return (opt.=
has_value() ? opt.value() : std::nullopt;</div><div>}</div><div><br></div><=
/div><div><br></div><div>The first one compiles, but the second one does no=
t (auto cannot simply deduce the type of nullopt, as it's basically an =
{} )</div><div>The third one is also something that I'd expect to be ab=
le to do, but the compiler does not allow unary return of such kind.</div><=
div><br></div><div>All the best,</div><div>Robert</div><div><br></div></div=
></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/894a072f-c1fc-4d6d-a37f-07a81f70a4ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/894a072f-c1fc-4d6d-a37f-07a81f70a4ea=
%40isocpp.org</a>.<br />
------=_Part_974_1133745266.1542328946651--
------=_Part_973_1184418834.1542328946651--
.
Author: mihailnajdenov@gmail.com
Date: Fri, 16 Nov 2018 00:57:03 -0800 (PST)
Raw View
------=_Part_938_621981447.1542358623802
Content-Type: multipart/alternative;
boundary="----=_Part_939_778877117.1542358623803"
------=_Part_939_778877117.1542358623803
Content-Type: text/plain; charset="UTF-8"
Naaaah
auto func()
{
if(something)
return std::common_type_t<std::string_view,
std::string>(std::string_view("sds"));
return std::common_type_t<std::string_view,
std::string>(std::string("sds"));
}
Boom.
On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>
>
> I disagree with the other responds. I actually think you have a point.
>
> nullopt and optional<int> are not totally "unrelated", specifically
> std::common_type< nullopt, optional<int> >::type === optional<int>.
>
> Suppose you have a function with several return statements returning type
> R1..Rn.
> The currently rules of auto return deduction is they all have to be the
> same type, and it will be deduced.
> But another reasonable option could have been that the deduced return type
> will be std::common_type<R...>::type.
>
> itaj
>
> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>
>> Hello everyone,
>> Is there any proposal floating regarding returning an uninitialized
>> optional?
>>
>> I'm referring to the following functions:
>>
>> std::optional<int> get1()
>> {
>> auto opt = make_optional<int>(4);
>> if (opt.has_value()) return opt;
>> return std::nullopt;
>> }
>>
>> auto get2()
>> {
>> auto opt = make_optional<int>(4);
>> if (opt.has_value()) return opt;
>> return std::nullopt;
>> }
>>
>> std::optional<int> get3()
>> {
>> auto opt = make_optional<int>(4);
>> return (opt.has_value() ? opt.value() : std::nullopt;
>> }
>>
>>
>> The first one compiles, but the second one does not (auto cannot simply
>> deduce the type of nullopt, as it's basically an {} )
>> The third one is also something that I'd expect to be able to do, but the
>> compiler does not allow unary return of such kind.
>>
>> All the best,
>> Robert
>>
>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-4ab0-9f65-9ec742b7df7a%40isocpp.org.
------=_Part_939_778877117.1542358623803
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Naaaah<div><br></div><div><div><font face=3D"courier new, =
monospace">auto func()</font></div><div><font face=3D"courier new, monospac=
e">{</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 i=
f(something)</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 return std::common_type_t<std::string_view, std::st=
ring>(std::string_view("sds"));</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 return std::common_type_t<std::st=
ring_view, std::string>(std::string("sds"));</font></div><div>=
<font face=3D"courier new, monospace">}</font></div></div><div><br>Boom.</d=
iv><div><br><br>On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sher=
man wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br=
>I disagree with the other responds. I actually think you have a point.<br>=
<br><div>nullopt and optional<int> are not totally "unrelated&qu=
ot;, specifically std::common_type< nullopt, optional<int> >::t=
ype =3D=3D=3D optional<int>.</div><div><br></div><div>Suppose you hav=
e a function with several return statements returning type R1..Rn.<br></div=
><div>The currently rules of auto return deduction is they all have to be t=
he same type, and it will be deduced.</div><div>But another reasonable opti=
on could have been that the deduced return type will be std::common_type<=
;R...>::type.</div><div><br></div><div>itaj<br></div><div><br></div><div=
>On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:<br></div>=
<div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyon=
e,=C2=A0<div>Is there any proposal floating regarding returning an uninitia=
lized optional?</div><div><br></div><div>I'm referring to the following=
functions:</div><div><br></div><div><div>std::optional<int> get1()</=
div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =3D m=
ake_optional<int>(4);</div><div><span style=3D"white-space:pre"> </sp=
an>if (opt.has_value()) return opt;</div><div><span style=3D"white-space:pr=
e"> </span>return std::nullopt;</div><div>}</div><div><br></div><div>auto g=
et2()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto op=
t =3D make_optional<int>(4);</div><div><span style=3D"white-space:pre=
"> </span>if (opt.has_value()) return opt;</div><div><span style=3D"white-s=
pace:pre"> </span>return std::nullopt;</div><div>}</div><div><br></div><div=
>std::optional<int> get3()</div><div>{</div><div><span style=3D"white=
-space:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><sp=
an style=3D"white-space:pre"> </span>return (opt.has_value() ? opt.value() =
: std::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>T=
he first one compiles, but the second one does not (auto cannot simply dedu=
ce the type of nullopt, as it's basically an {} )</div><div>The third o=
ne is also something that I'd expect to be able to do, but the compiler=
does not allow unary return of such kind.</div><div><br></div><div>All the=
best,</div><div>Robert</div><div><br></div></div></blockquote></div></div>=
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-4ab0-9f65-9ec742b7df7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-4ab0-9f65-9ec742b7df7a=
%40isocpp.org</a>.<br />
------=_Part_939_778877117.1542358623803--
------=_Part_938_621981447.1542358623802--
.
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Fri, 16 Nov 2018 10:33:12 +0000
Raw View
--0000000000006886f3057ac5b29d
Content-Type: text/plain; charset="UTF-8"
+1 to Mihail's example, especially since more than half the time, the two
values will be coming from some inscrutable function call. It's when I get
to my
template <typename T> struct undefined;
undefined<decltype(what_is_this)>{};
trick to even find what the type is.
It's really not that much of a problem to just decltype() the return you
think has the right type and just initialize the others from it, is it, if
you already can't use a trailing return type?
Magic is powerful, but needs to be used judiciously. This is the decidedly,
"no thank you, no magic for me today" part of the language.
G
On Fri, Nov 16, 2018 at 8:57 AM <mihailnajdenov@gmail.com> wrote:
> Naaaah
>
> auto func()
> {
> if(something)
> return std::common_type_t<std::string_view,
> std::string>(std::string_view("sds"));
>
> return std::common_type_t<std::string_view,
> std::string>(std::string("sds"));
> }
>
> Boom.
>
>
> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>
>>
>> I disagree with the other responds. I actually think you have a point.
>>
>> nullopt and optional<int> are not totally "unrelated", specifically
>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>
>> Suppose you have a function with several return statements returning type
>> R1..Rn.
>> The currently rules of auto return deduction is they all have to be the
>> same type, and it will be deduced.
>> But another reasonable option could have been that the deduced return
>> type will be std::common_type<R...>::type.
>>
>> itaj
>>
>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>
>>> Hello everyone,
>>> Is there any proposal floating regarding returning an uninitialized
>>> optional?
>>>
>>> I'm referring to the following functions:
>>>
>>> std::optional<int> get1()
>>> {
>>> auto opt = make_optional<int>(4);
>>> if (opt.has_value()) return opt;
>>> return std::nullopt;
>>> }
>>>
>>> auto get2()
>>> {
>>> auto opt = make_optional<int>(4);
>>> if (opt.has_value()) return opt;
>>> return std::nullopt;
>>> }
>>>
>>> std::optional<int> get3()
>>> {
>>> auto opt = make_optional<int>(4);
>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>> }
>>>
>>>
>>> The first one compiles, but the second one does not (auto cannot simply
>>> deduce the type of nullopt, as it's basically an {} )
>>> The third one is also something that I'd expect to be able to do, but
>>> the compiler does not allow unary return of such kind.
>>>
>>> All the best,
>>> Robert
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-4ab0-9f65-9ec742b7df7a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-4ab0-9f65-9ec742b7df7a%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXuHrf-_hm7YhgDJPnyqDAvR%2BfiwjqXQuE5dbhisXtjbw%40mail.gmail.com.
--0000000000006886f3057ac5b29d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1 to Mihail's example, especially since more than hal=
f the time, the two values will be coming from some inscrutable function ca=
ll. It's when I get to my=C2=A0<div><br></div><div>template <typenam=
e T> struct undefined;</div><div>undefined<decltype(what_is_this)>=
{};</div><div><br></div><div>trick to even find what the type is.</div><div=
><br></div><div>It's really not that much of a problem to just decltype=
() the return you think has the right type and just initialize the others f=
rom it, is it, if you already can't use a trailing return type?</div><d=
iv><br></div><div>Magic is powerful, but needs to be used judiciously. This=
is the decidedly, "no thank you, no magic for me today" part of =
the language.</div><div><br></div><div>G</div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr">On Fri, Nov 16, 2018 at 8:57 AM <<a href=3D"mai=
lto:mihailnajdenov@gmail.com">mihailnajdenov@gmail.com</a>> wrote:<br></=
div><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">Naaaah<div><br></div><d=
iv><div><font face=3D"courier new, monospace">auto func()</font></div><div>=
<font face=3D"courier new, monospace">{</font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 if(something)</font></div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::common_=
type_t<std::string_view, std::string>(std::string_view("sds"=
;));</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
=C2=A0</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
return std::common_type_t<std::string_view, std::string>(std::string=
("sds"));</font></div><div><font face=3D"courier new, monospace">=
}</font></div></div><div><br>Boom.</div><div><br><br>On Friday, November 16=
, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><br>I disagree with the other responds. I actu=
ally think you have a point.<br><br><div>nullopt and optional<int> ar=
e not totally "unrelated", specifically std::common_type< null=
opt, optional<int> >::type =3D=3D=3D optional<int>.</div><di=
v><br></div><div>Suppose you have a function with several return statements=
returning type R1..Rn.<br></div><div>The currently rules of auto return de=
duction is they all have to be the same type, and it will be deduced.</div>=
<div>But another reasonable option could have been that the deduced return =
type will be std::common_type<R...>::type.</div><div><br></div><div>i=
taj<br></div><div><br></div><div>On Monday, 12 November 2018 08:18:59 UTC+2=
, robert badea wrote:<br></div><div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Hello everyone,=C2=A0<div>Is there any proposal floating=
regarding returning an uninitialized optional?</div><div><br></div><div>I&=
#39;m referring to the following functions:</div><div><br></div><div><div>s=
td::optional<int> get1()</div><div>{</div><div><span style=3D"white-s=
pace:pre-wrap"> </span>auto opt =3D make_optional<int>(4);</div><div>=
<span style=3D"white-space:pre-wrap"> </span>if (opt.has_value()) return op=
t;</div><div><span style=3D"white-space:pre-wrap"> </span>return std::nullo=
pt;</div><div>}</div><div><br></div><div>auto get2()</div><div>{</div><div>=
<span style=3D"white-space:pre-wrap"> </span>auto opt =3D make_optional<=
int>(4);</div><div><span style=3D"white-space:pre-wrap"> </span>if (opt.=
has_value()) return opt;</div><div><span style=3D"white-space:pre-wrap"> </=
span>return std::nullopt;</div><div>}</div><div><br></div><div>std::optiona=
l<int> get3()</div><div>{</div><div><span style=3D"white-space:pre-wr=
ap"> </span>auto opt =3D make_optional<int>(4);</div><div><span style=
=3D"white-space:pre-wrap"> </span>return (opt.has_value() ? opt.value() : s=
td::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>The =
first one compiles, but the second one does not (auto cannot simply deduce =
the type of nullopt, as it's basically an {} )</div><div>The third one =
is also something that I'd expect to be able to do, but the compiler do=
es not allow unary return of such kind.</div><div><br></div><div>All the be=
st,</div><div>Robert</div><div><br></div></div></blockquote></div></div></b=
lockquote></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-4ab0-9f65-9ec742b7df7a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9027ed3-a8af-=
4ab0-9f65-9ec742b7df7a%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXuHrf-_hm7YhgDJPnyqDAvR%2Bfi=
wjqXQuE5dbhisXtjbw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXuHr=
f-_hm7YhgDJPnyqDAvR%2BfiwjqXQuE5dbhisXtjbw%40mail.gmail.com</a>.<br />
--0000000000006886f3057ac5b29d--
.
Author: Itaj Sherman <itajsherman@gmail.com>
Date: Fri, 16 Nov 2018 03:19:21 -0800 (PST)
Raw View
------=_Part_919_792523073.1542367161536
Content-Type: multipart/alternative;
boundary="----=_Part_920_964191603.1542367161536"
------=_Part_920_964191603.1542367161536
Content-Type: text/plain; charset="UTF-8"
Yeah, true.
It will require some sort of is_stable_valid<T> trait that says a type can
be safely returned because it doesn't depend on non-owned addresses.
so value types and owner-pointers can be is_stable_valid<T>, while observer
pointers, iterators and views cannot.
wrappers like optional, variant, tuple will be is_stable_valid if all their
elements are.
if auto function has different return types is can return
enable_if_stable_valid_t< commot_type_t<R...> >
template< typename T > using enable_if_stable_valid_t = enable_if<
is_stable_valid<T>, T >::type;
an even more generalized notion would be:
is_stably_convertible< S, R >
which will specify that is_convertible< S, R >, and that the resulting R is
no less stable than S.
and define stably_common_type_t< R... > based on is_stably_convertible.
formally:
define the instability-set of and object X as the set of objects whose
lifetime X doesn't own, but still requires them to be alive for X's
contract - depending on the user to make sure they stay alive.
and is_stably_convertible< S, R > means that
1 - the instability set of the resulting R is contained within the
instability set of the source S
2 - resulting R doesn't own any objects from the instability set of S (that
is it doesn't initiate ownership on it).
so basically if is_stable_valid<T> then instability set is empty.
T* x = &a; //instability set is {a}
T** y = &x; //instability set is {x,a}
std::variant<int, T*> z = x; //instability set is {a}
basically:
is_stably_convertible< T, optional<T> > == true
is_stably_convertible< T*, optional<T*> > == true
is_stably_convertible< string, string_view > == false
is_stably_convertible< string_view, string > == true
is_stably_convertible< shared_ptr/unique_ptr, T* > == false //both because
the conversion is not implicit, and even if it were, the instability set of
the result is bigger.
is_stably_convertible< T*, shared_ptr/unique_ptr > == false //both because
the conversion is not implicit, and even if it were, it would take
ownership on the unowned.
this can also improve safety with the extended lifetime of temporary
bounded to reference:
T& = expression; //if expression is temporary, will require
is_stably_convertible< typeof(expression), T >, otherwise ill-formed.
itaj
On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.com wrote:
>
> Naaaah
>
> auto func()
> {
> if(something)
> return std::common_type_t<std::string_view,
> std::string>(std::string_view("sds"));
>
> return std::common_type_t<std::string_view,
> std::string>(std::string("sds"));
> }
>
> Boom.
>
>
> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>
>>
>> I disagree with the other responds. I actually think you have a point.
>>
>> nullopt and optional<int> are not totally "unrelated", specifically
>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>
>> Suppose you have a function with several return statements returning type
>> R1..Rn.
>> The currently rules of auto return deduction is they all have to be the
>> same type, and it will be deduced.
>> But another reasonable option could have been that the deduced return
>> type will be std::common_type<R...>::type.
>>
>> itaj
>>
>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>
>>> Hello everyone,
>>> Is there any proposal floating regarding returning an uninitialized
>>> optional?
>>>
>>> I'm referring to the following functions:
>>>
>>> std::optional<int> get1()
>>> {
>>> auto opt = make_optional<int>(4);
>>> if (opt.has_value()) return opt;
>>> return std::nullopt;
>>> }
>>>
>>> auto get2()
>>> {
>>> auto opt = make_optional<int>(4);
>>> if (opt.has_value()) return opt;
>>> return std::nullopt;
>>> }
>>>
>>> std::optional<int> get3()
>>> {
>>> auto opt = make_optional<int>(4);
>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>> }
>>>
>>>
>>> The first one compiles, but the second one does not (auto cannot simply
>>> deduce the type of nullopt, as it's basically an {} )
>>> The third one is also something that I'd expect to be able to do, but
>>> the compiler does not allow unary return of such kind.
>>>
>>> All the best,
>>> Robert
>>>
>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81aeef78-e8b2-439a-a6b0-3136a711d9f4%40isocpp.org.
------=_Part_920_964191603.1542367161536
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Yeah, true.<br><br>It will require some sort of is_sta=
ble_valid<T> trait that says a type can be safely returned because it=
doesn't depend on non-owned addresses.<br><div><br></div><div>so value=
types and owner-pointers can be is_stable_valid<T>, while observer p=
ointers, iterators and views cannot.</div><div>wrappers like optional, vari=
ant, tuple will be is_stable_valid if all their elements are.</div><div><br=
></div><div>if auto function has different return types is can return enabl=
e_if_stable_valid_t< commot_type_t<R...> ><br></div><div>templa=
te< typename T > using enable_if_stable_valid_t =3D enable_if< is_=
stable_valid<T>, T >::type;<br></div><div><br></div><div><br></div=
><div>an even more generalized notion would be:</div><div><br></div><div><d=
iv>is_stably_convertible< S, R ></div><div>which will specify that is=
_convertible< S, R >, and that the resulting R is no less stable than=
S.</div><div>and define stably_common_type_t< R... > based on is_sta=
bly_convertible.<br><br>formally:</div></div><div>define the instability-se=
t of and object X as the set of objects whose lifetime X doesn't own, b=
ut still requires them to be alive for X's contract - depending on the =
user to make sure they stay alive.</div><div><br></div><div><div>and is_sta=
bly_convertible< S, R > means that=C2=A0</div><div>1 - the instabilit=
y set of the resulting R is contained within the instability set of the sou=
rce S</div><div>2 - resulting R doesn't own any objects from the instab=
ility set of S (that is it doesn't initiate ownership on it).</div></di=
v><div><br></div><div>so basically if is_stable_valid<T> then instabi=
lity set is empty.<br></div><div>T* x =3D &a; //instability set is {a}<=
/div><div>T** y =3D &x; //instability set is {x,a}</div><div>std::varia=
nt<int, T*> z =3D x; //instability set is {a}</div><div><br></div><di=
v>basically:<br></div><div>is_stably_convertible< T, optional<T> &=
gt; =3D=3D true</div><div></div><div>is_stably_convertible< T*, optional=
<T*> > =3D=3D true</div><div><div>is_stably_convertible< string=
, string_view > =3D=3D false<br></div></div><div><div>is_stably_converti=
ble< string_view, string > =3D=3D true<br></div></div><div><div>is_st=
ably_convertible< shared_ptr/unique_ptr, T* > =3D=3D false //both bec=
ause the conversion is not implicit, and even if it were, the instability s=
et of the result is bigger.<br></div></div><div>is_stably_convertible< T=
*, shared_ptr/unique_ptr > =3D=3D false //both because the conversion is=
not implicit, and even if it were, it would take ownership on the unowned.=
<br></div><div><br></div><div>this can also improve safety with the extende=
d lifetime of temporary bounded to reference:<br><br>T& =3D expression;=
//if expression is temporary, will require is_stably_convertible< typeo=
f(expression), T >, otherwise ill-formed.</div><div><br></div><div>itaj<=
/div><div><br>On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.=
com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Na=
aaah<div><br></div><div><div><font face=3D"courier new, monospace">auto fun=
c()</font></div><div><font face=3D"courier new, monospace">{</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if(something)</font>=
</div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 return std::common_type_t<std::<wbr>string_view, std::string>(std=
::string_view(<wbr>"sds"));</font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0 return std::common_type_t<std::<wbr>stri=
ng_view, std::string>(std::string("sds"<wbr>));</font></div><d=
iv><font face=3D"courier new, monospace">}</font></div></div><div><br>Boom.=
</div><div><br><br>On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj S=
herman wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I=
disagree with the other responds. I actually think you have a point.<br><b=
r><div>nullopt and optional<int> are not totally "unrelated"=
;, specifically std::common_type< nullopt, optional<int> >::typ=
e =3D=3D=3D optional<int>.</div><div><br></div><div>Suppose you have =
a function with several return statements returning type R1..Rn.<br></div><=
div>The currently rules of auto return deduction is they all have to be the=
same type, and it will be deduced.</div><div>But another reasonable option=
could have been that the deduced return type will be std::common_type<R=
....>::type.</div><div><br></div><div>itaj<br></div><div><br></div><div>O=
n Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:<br></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 dir=3D"ltr">Hello everyone,=
=C2=A0<div>Is there any proposal floating regarding returning an uninitiali=
zed optional?</div><div><br></div><div>I'm referring to the following f=
unctions:</div><div><br></div><div><div>std::optional<int> get1()</di=
v><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =3D mak=
e_optional<int>(4);</div><div><span style=3D"white-space:pre"> </span=
>if (opt.has_value()) return opt;</div><div><span style=3D"white-space:pre"=
> </span>return std::nullopt;</div><div>}</div><div><br></div><div>auto get=
2()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =
=3D make_optional<int>(4);</div><div><span style=3D"white-space:pre">=
</span>if (opt.has_value()) return opt;</div><div><span style=3D"white-spa=
ce:pre"> </span>return std::nullopt;</div><div>}</div><div><br></div><div>s=
td::optional<int> get3()</div><div>{</div><div><span style=3D"white-s=
pace:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><span=
style=3D"white-space:pre"> </span>return (opt.has_value() ? opt.value() : =
std::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>The=
first one compiles, but the second one does not (auto cannot simply deduce=
the type of nullopt, as it's basically an {} )</div><div>The third one=
is also something that I'd expect to be able to do, but the compiler d=
oes not allow unary return of such kind.</div><div><br></div><div>All the b=
est,</div><div>Robert</div><div><br></div></div></blockquote></div></div></=
blockquote></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/81aeef78-e8b2-439a-a6b0-3136a711d9f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81aeef78-e8b2-439a-a6b0-3136a711d9f4=
%40isocpp.org</a>.<br />
------=_Part_920_964191603.1542367161536--
------=_Part_919_792523073.1542367161536--
.
Author: Itaj Sherman <itajsherman@gmail.com>
Date: Fri, 16 Nov 2018 03:40:11 -0800 (PST)
Raw View
------=_Part_1120_414645652.1542368411251
Content-Type: multipart/alternative;
boundary="----=_Part_1121_1599456038.1542368411251"
------=_Part_1121_1599456038.1542368411251
Content-Type: text/plain; charset="UTF-8"
Probably more cases could improve safety. The following syntaxes also allow
any implicit conversion, and might benefit from only allowing
stably_convertible ones:
T x = EXPRESSION_WITH_TEMPORARY_RESULT;
T foo() { return EXPRESSION_WITH_TEMPORARY_RESULT; }
On Friday, 16 November 2018 13:19:21 UTC+2, Itaj Sherman wrote:
>
>
> Yeah, true.
>
> It will require some sort of is_stable_valid<T> trait that says a type can
> be safely returned because it doesn't depend on non-owned addresses.
>
> so value types and owner-pointers can be is_stable_valid<T>, while
> observer pointers, iterators and views cannot.
> wrappers like optional, variant, tuple will be is_stable_valid if all
> their elements are.
>
> if auto function has different return types is can return
> enable_if_stable_valid_t< commot_type_t<R...> >
> template< typename T > using enable_if_stable_valid_t = enable_if<
> is_stable_valid<T>, T >::type;
>
>
> an even more generalized notion would be:
>
> is_stably_convertible< S, R >
> which will specify that is_convertible< S, R >, and that the resulting R
> is no less stable than S.
> and define stably_common_type_t< R... > based on is_stably_convertible.
>
> formally:
> define the instability-set of and object X as the set of objects whose
> lifetime X doesn't own, but still requires them to be alive for X's
> contract - depending on the user to make sure they stay alive.
>
> and is_stably_convertible< S, R > means that
> 1 - the instability set of the resulting R is contained within the
> instability set of the source S
> 2 - resulting R doesn't own any objects from the instability set of S
> (that is it doesn't initiate ownership on it).
>
> so basically if is_stable_valid<T> then instability set is empty.
> T* x = &a; //instability set is {a}
> T** y = &x; //instability set is {x,a}
> std::variant<int, T*> z = x; //instability set is {a}
>
> basically:
> is_stably_convertible< T, optional<T> > == true
> is_stably_convertible< T*, optional<T*> > == true
> is_stably_convertible< string, string_view > == false
> is_stably_convertible< string_view, string > == true
> is_stably_convertible< shared_ptr/unique_ptr, T* > == false //both because
> the conversion is not implicit, and even if it were, the instability set of
> the result is bigger.
> is_stably_convertible< T*, shared_ptr/unique_ptr > == false //both because
> the conversion is not implicit, and even if it were, it would take
> ownership on the unowned.
>
> this can also improve safety with the extended lifetime of temporary
> bounded to reference:
>
> T& = expression; //if expression is temporary, will require
> is_stably_convertible< typeof(expression), T >, otherwise ill-formed.
>
> itaj
>
> On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.com wrote:
>>
>> Naaaah
>>
>> auto func()
>> {
>> if(something)
>> return std::common_type_t<std::string_view,
>> std::string>(std::string_view("sds"));
>>
>> return std::common_type_t<std::string_view,
>> std::string>(std::string("sds"));
>> }
>>
>> Boom.
>>
>>
>> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>>
>>>
>>> I disagree with the other responds. I actually think you have a point.
>>>
>>> nullopt and optional<int> are not totally "unrelated", specifically
>>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>>
>>> Suppose you have a function with several return statements returning
>>> type R1..Rn.
>>> The currently rules of auto return deduction is they all have to be the
>>> same type, and it will be deduced.
>>> But another reasonable option could have been that the deduced return
>>> type will be std::common_type<R...>::type.
>>>
>>> itaj
>>>
>>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>>
>>>> Hello everyone,
>>>> Is there any proposal floating regarding returning an uninitialized
>>>> optional?
>>>>
>>>> I'm referring to the following functions:
>>>>
>>>> std::optional<int> get1()
>>>> {
>>>> auto opt = make_optional<int>(4);
>>>> if (opt.has_value()) return opt;
>>>> return std::nullopt;
>>>> }
>>>>
>>>> auto get2()
>>>> {
>>>> auto opt = make_optional<int>(4);
>>>> if (opt.has_value()) return opt;
>>>> return std::nullopt;
>>>> }
>>>>
>>>> std::optional<int> get3()
>>>> {
>>>> auto opt = make_optional<int>(4);
>>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>>> }
>>>>
>>>>
>>>> The first one compiles, but the second one does not (auto cannot simply
>>>> deduce the type of nullopt, as it's basically an {} )
>>>> The third one is also something that I'd expect to be able to do, but
>>>> the compiler does not allow unary return of such kind.
>>>>
>>>> All the best,
>>>> Robert
>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ec1dbc21-04ae-464f-bba5-318eda049ef8%40isocpp.org.
------=_Part_1121_1599456038.1542368411251
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Probably more cases could improve safety. The following sy=
ntaxes also allow any implicit conversion, and might benefit from only allo=
wing stably_convertible ones:<br><br>T x =3D EXPRESSION_WITH_TEMPORARY_RESU=
LT;<div><br></div><div>T foo() { return EXPRESSION_WITH_TEMPORARY_RESULT; }=
</div><div><br></div><div><br></div><div>On Friday, 16 November 2018 13:19:=
21 UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><br>Yeah, true.<br><br>It will require some sort of is_sta=
ble_valid<T> trait that says a type can be safely returned because it=
doesn't depend on non-owned addresses.<br><div><br></div><div>so value=
types and owner-pointers can be is_stable_valid<T>, while observer p=
ointers, iterators and views cannot.</div><div>wrappers like optional, vari=
ant, tuple will be is_stable_valid if all their elements are.</div><div><br=
></div><div>if auto function has different return types is can return enabl=
e_if_stable_valid_t< commot_type_t<R...> ><br></div><div>templa=
te< typename T > using enable_if_stable_valid_t =3D enable_if< is_=
stable_valid<T>, T >::type;<br></div><div><br></div><div><br></div=
><div>an even more generalized notion would be:</div><div><br></div><div><d=
iv>is_stably_convertible< S, R ></div><div>which will specify that is=
_convertible< S, R >, and that the resulting R is no less stable than=
S.</div><div>and define stably_common_type_t< R... > based on is_sta=
bly_convertible.<br><br>formally:</div></div><div>define the instability-se=
t of and object X as the set of objects whose lifetime X doesn't own, b=
ut still requires them to be alive for X's contract - depending on the =
user to make sure they stay alive.</div><div><br></div><div><div>and is_sta=
bly_convertible< S, R > means that=C2=A0</div><div>1 - the instabilit=
y set of the resulting R is contained within the instability set of the sou=
rce S</div><div>2 - resulting R doesn't own any objects from the instab=
ility set of S (that is it doesn't initiate ownership on it).</div></di=
v><div><br></div><div>so basically if is_stable_valid<T> then instabi=
lity set is empty.<br></div><div>T* x =3D &a; //instability set is {a}<=
/div><div>T** y =3D &x; //instability set is {x,a}</div><div>std::varia=
nt<int, T*> z =3D x; //instability set is {a}</div><div><br></div><di=
v>basically:<br></div><div>is_stably_convertible< T, optional<T> &=
gt; =3D=3D true</div><div></div><div>is_stably_convertible< T*, optional=
<T*> > =3D=3D true</div><div><div>is_stably_convertible< string=
, string_view > =3D=3D false<br></div></div><div><div>is_stably_converti=
ble< string_view, string > =3D=3D true<br></div></div><div><div>is_st=
ably_convertible< shared_ptr/unique_ptr, T* > =3D=3D false //both bec=
ause the conversion is not implicit, and even if it were, the instability s=
et of the result is bigger.<br></div></div><div>is_stably_convertible< T=
*, shared_ptr/unique_ptr > =3D=3D false //both because the conversion is=
not implicit, and even if it were, it would take ownership on the unowned.=
<br></div><div><br></div><div>this can also improve safety with the extende=
d lifetime of temporary bounded to reference:<br><br>T& =3D expression;=
//if expression is temporary, will require is_stably_convertible< typeo=
f(expression), T >, otherwise ill-formed.</div><div><br></div><div>itaj<=
/div><div><br>On Friday, 16 November 2018 10:57:03 UTC+2, <a>mihailn...@gma=
il.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
Naaaah<div><br></div><div><div><font face=3D"courier new, monospace">auto f=
unc()</font></div><div><font face=3D"courier new, monospace">{</font></div>=
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if(something)</fon=
t></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 return std::common_type_t<std::<wbr>string_view, std::string>(std=
::string_view(<wbr>"sds"));</font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0 return std::common_type_t<std::<wbr>stri=
ng_view, std::string>(std::string("sds"<wbr>));</font></div><d=
iv><font face=3D"courier new, monospace">}</font></div></div><div><br>Boom.=
</div><div><br><br>On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj S=
herman wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I=
disagree with the other responds. I actually think you have a point.<br><b=
r><div>nullopt and optional<int> are not totally "unrelated"=
;, specifically std::common_type< nullopt, optional<int> >::typ=
e =3D=3D=3D optional<int>.</div><div><br></div><div>Suppose you have =
a function with several return statements returning type R1..Rn.<br></div><=
div>The currently rules of auto return deduction is they all have to be the=
same type, and it will be deduced.</div><div>But another reasonable option=
could have been that the deduced return type will be std::common_type<R=
....>::type.</div><div><br></div><div>itaj<br></div><div><br></div><div>O=
n Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:<br></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 dir=3D"ltr">Hello everyone,=
=C2=A0<div>Is there any proposal floating regarding returning an uninitiali=
zed optional?</div><div><br></div><div>I'm referring to the following f=
unctions:</div><div><br></div><div><div>std::optional<int> get1()</di=
v><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =3D mak=
e_optional<int>(4);</div><div><span style=3D"white-space:pre"> </span=
>if (opt.has_value()) return opt;</div><div><span style=3D"white-space:pre"=
> </span>return std::nullopt;</div><div>}</div><div><br></div><div>auto get=
2()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =
=3D make_optional<int>(4);</div><div><span style=3D"white-space:pre">=
</span>if (opt.has_value()) return opt;</div><div><span style=3D"white-spa=
ce:pre"> </span>return std::nullopt;</div><div>}</div><div><br></div><div>s=
td::optional<int> get3()</div><div>{</div><div><span style=3D"white-s=
pace:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><span=
style=3D"white-space:pre"> </span>return (opt.has_value() ? opt.value() : =
std::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>The=
first one compiles, but the second one does not (auto cannot simply deduce=
the type of nullopt, as it's basically an {} )</div><div>The third one=
is also something that I'd expect to be able to do, but the compiler d=
oes not allow unary return of such kind.</div><div><br></div><div>All the b=
est,</div><div>Robert</div><div><br></div></div></blockquote></div></div></=
blockquote></div></div></blockquote></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ec1dbc21-04ae-464f-bba5-318eda049ef8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ec1dbc21-04ae-464f-bba5-318eda049ef8=
%40isocpp.org</a>.<br />
------=_Part_1121_1599456038.1542368411251--
------=_Part_1120_414645652.1542368411251--
.
Author: Itaj Sherman <itajsherman@gmail.com>
Date: Fri, 16 Nov 2018 03:44:12 -0800 (PST)
Raw View
------=_Part_1066_1942040189.1542368652706
Content-Type: multipart/alternative;
boundary="----=_Part_1067_542738280.1542368652707"
------=_Part_1067_542738280.1542368652707
Content-Type: text/plain; charset="UTF-8"
and constructors like
string_view::string_view( std::string const& )
which are not marked with the 'explicit' keywords, because they are useful
in many implicit cases,
could be marked with a new keyword 'instable' to set stably_convertible to
false.
On Friday, 16 November 2018 13:40:11 UTC+2, Itaj Sherman wrote:
>
> Probably more cases could improve safety. The following syntaxes also
> allow any implicit conversion, and might benefit from only allowing
> stably_convertible ones:
>
> T x = EXPRESSION_WITH_TEMPORARY_RESULT;
>
> T foo() { return EXPRESSION_WITH_TEMPORARY_RESULT; }
>
>
> On Friday, 16 November 2018 13:19:21 UTC+2, Itaj Sherman wrote:
>>
>>
>> Yeah, true.
>>
>> It will require some sort of is_stable_valid<T> trait that says a type
>> can be safely returned because it doesn't depend on non-owned addresses.
>>
>> so value types and owner-pointers can be is_stable_valid<T>, while
>> observer pointers, iterators and views cannot.
>> wrappers like optional, variant, tuple will be is_stable_valid if all
>> their elements are.
>>
>> if auto function has different return types is can return
>> enable_if_stable_valid_t< commot_type_t<R...> >
>> template< typename T > using enable_if_stable_valid_t = enable_if<
>> is_stable_valid<T>, T >::type;
>>
>>
>> an even more generalized notion would be:
>>
>> is_stably_convertible< S, R >
>> which will specify that is_convertible< S, R >, and that the resulting R
>> is no less stable than S.
>> and define stably_common_type_t< R... > based on is_stably_convertible.
>>
>> formally:
>> define the instability-set of and object X as the set of objects whose
>> lifetime X doesn't own, but still requires them to be alive for X's
>> contract - depending on the user to make sure they stay alive.
>>
>> and is_stably_convertible< S, R > means that
>> 1 - the instability set of the resulting R is contained within the
>> instability set of the source S
>> 2 - resulting R doesn't own any objects from the instability set of S
>> (that is it doesn't initiate ownership on it).
>>
>> so basically if is_stable_valid<T> then instability set is empty.
>> T* x = &a; //instability set is {a}
>> T** y = &x; //instability set is {x,a}
>> std::variant<int, T*> z = x; //instability set is {a}
>>
>> basically:
>> is_stably_convertible< T, optional<T> > == true
>> is_stably_convertible< T*, optional<T*> > == true
>> is_stably_convertible< string, string_view > == false
>> is_stably_convertible< string_view, string > == true
>> is_stably_convertible< shared_ptr/unique_ptr, T* > == false //both
>> because the conversion is not implicit, and even if it were, the
>> instability set of the result is bigger.
>> is_stably_convertible< T*, shared_ptr/unique_ptr > == false //both
>> because the conversion is not implicit, and even if it were, it would take
>> ownership on the unowned.
>>
>> this can also improve safety with the extended lifetime of temporary
>> bounded to reference:
>>
>> T& = expression; //if expression is temporary, will require
>> is_stably_convertible< typeof(expression), T >, otherwise ill-formed.
>>
>> itaj
>>
>> On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.com wrote:
>>>
>>> Naaaah
>>>
>>> auto func()
>>> {
>>> if(something)
>>> return std::common_type_t<std::string_view,
>>> std::string>(std::string_view("sds"));
>>>
>>> return std::common_type_t<std::string_view,
>>> std::string>(std::string("sds"));
>>> }
>>>
>>> Boom.
>>>
>>>
>>> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>>>
>>>>
>>>> I disagree with the other responds. I actually think you have a point.
>>>>
>>>> nullopt and optional<int> are not totally "unrelated", specifically
>>>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>>>
>>>> Suppose you have a function with several return statements returning
>>>> type R1..Rn.
>>>> The currently rules of auto return deduction is they all have to be the
>>>> same type, and it will be deduced.
>>>> But another reasonable option could have been that the deduced return
>>>> type will be std::common_type<R...>::type.
>>>>
>>>> itaj
>>>>
>>>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>>>
>>>>> Hello everyone,
>>>>> Is there any proposal floating regarding returning an uninitialized
>>>>> optional?
>>>>>
>>>>> I'm referring to the following functions:
>>>>>
>>>>> std::optional<int> get1()
>>>>> {
>>>>> auto opt = make_optional<int>(4);
>>>>> if (opt.has_value()) return opt;
>>>>> return std::nullopt;
>>>>> }
>>>>>
>>>>> auto get2()
>>>>> {
>>>>> auto opt = make_optional<int>(4);
>>>>> if (opt.has_value()) return opt;
>>>>> return std::nullopt;
>>>>> }
>>>>>
>>>>> std::optional<int> get3()
>>>>> {
>>>>> auto opt = make_optional<int>(4);
>>>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>>>> }
>>>>>
>>>>>
>>>>> The first one compiles, but the second one does not (auto cannot
>>>>> simply deduce the type of nullopt, as it's basically an {} )
>>>>> The third one is also something that I'd expect to be able to do, but
>>>>> the compiler does not allow unary return of such kind.
>>>>>
>>>>> All the best,
>>>>> Robert
>>>>>
>>>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/de619d9b-2bcd-4ed0-84f5-3e7d631a3dd4%40isocpp.org.
------=_Part_1067_542738280.1542368652707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">and constructors like=C2=A0<div>string_view::string_view( =
std::string const& )</div><div><br></div><div>which are not marked with=
the 'explicit' keywords, because they are useful in many implicit =
cases,</div><div>could be marked with a new keyword 'instable' to s=
et stably_convertible to false.<br><br>On Friday, 16 November 2018 13:40:11=
UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Probably more cases could improve safety. The following synt=
axes also allow any implicit conversion, and might benefit from only allowi=
ng stably_convertible ones:<br><br>T x =3D EXPRESSION_WITH_TEMPORARY_<wbr>R=
ESULT;<div><br></div><div>T foo() { return EXPRESSION_WITH_TEMPORARY_<wbr>R=
ESULT; }</div><div><br></div><div><br></div><div>On Friday, 16 November 201=
8 13:19:21 UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><br>Yeah, true.<br><br>It will require some sort of is_=
stable_valid<T> trait that says a type can be safely returned because=
it doesn't depend on non-owned addresses.<br><div><br></div><div>so va=
lue types and owner-pointers can be is_stable_valid<T>, while observe=
r pointers, iterators and views cannot.</div><div>wrappers like optional, v=
ariant, tuple will be is_stable_valid if all their elements are.</div><div>=
<br></div><div>if auto function has different return types is can return en=
able_if_stable_valid_t< commot_type_t<R...> ><br></div><div>tem=
plate< typename T > using enable_if_stable_valid_t =3D enable_if< =
is_stable_valid<T>, T >::type;<br></div><div><br></div><div><br></=
div><div>an even more generalized notion would be:</div><div><br></div><div=
><div>is_stably_convertible< S, R ></div><div>which will specify that=
is_convertible< S, R >, and that the resulting R is no less stable t=
han S.</div><div>and define stably_common_type_t< R... > based on is_=
stably_convertible.<br><br>formally:</div></div><div>define the instability=
-set of and object X as the set of objects whose lifetime X doesn't own=
, but still requires them to be alive for X's contract - depending on t=
he user to make sure they stay alive.</div><div><br></div><div><div>and is_=
stably_convertible< S, R > means that=C2=A0</div><div>1 - the instabi=
lity set of the resulting R is contained within the instability set of the =
source S</div><div>2 - resulting R doesn't own any objects from the ins=
tability set of S (that is it doesn't initiate ownership on it).</div><=
/div><div><br></div><div>so basically if is_stable_valid<T> then inst=
ability set is empty.<br></div><div>T* x =3D &a; //instability set is {=
a}</div><div>T** y =3D &x; //instability set is {x,a}</div><div>std::va=
riant<int, T*> z =3D x; //instability set is {a}</div><div><br></div>=
<div>basically:<br></div><div>is_stably_convertible< T, optional<T>=
; > =3D=3D true</div><div></div><div>is_stably_convertible< T*, optio=
nal<T*> > =3D=3D true</div><div><div>is_stably_convertible< str=
ing, string_view > =3D=3D false<br></div></div><div><div>is_stably_conve=
rtible< string_view, string > =3D=3D true<br></div></div><div><div>is=
_stably_convertible< shared_ptr/unique_ptr, T* > =3D=3D false //both =
because the conversion is not implicit, and even if it were, the instabilit=
y set of the result is bigger.<br></div></div><div>is_stably_convertible<=
; T*, shared_ptr/unique_ptr > =3D=3D false //both because the conversion=
is not implicit, and even if it were, it would take ownership on the unown=
ed.<br></div><div><br></div><div>this can also improve safety with the exte=
nded lifetime of temporary bounded to reference:<br><br>T& =3D expressi=
on; //if expression is temporary, will require is_stably_convertible< ty=
peof(expression), T >, otherwise ill-formed.</div><div><br></div><div>it=
aj</div><div><br>On Friday, 16 November 2018 10:57:03 UTC+2, <a>mihailn...@=
gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Naaaah<div><br></div><div><div><font face=3D"courier new, monospace">aut=
o func()</font></div><div><font face=3D"courier new, monospace">{</font></d=
iv><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if(something)</=
font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return std::common_type_t<std::<wbr>string_view, std::string>(=
std::string_view(<wbr>"sds"));</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 return std::common_type_t<std::<wbr>s=
tring_view, std::string>(std::string("sds"<wbr>));</font></div=
><div><font face=3D"courier new, monospace">}</font></div></div><div><br>Bo=
om.</div><div><br><br>On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Ita=
j Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r>I disagree with the other responds. I actually think you have a point.<br=
><br><div>nullopt and optional<int> are not totally "unrelated&q=
uot;, specifically std::common_type< nullopt, optional<int> >::=
type =3D=3D=3D optional<int>.</div><div><br></div><div>Suppose you ha=
ve a function with several return statements returning type R1..Rn.<br></di=
v><div>The currently rules of auto return deduction is they all have to be =
the same type, and it will be deduced.</div><div>But another reasonable opt=
ion could have been that the deduced return type will be std::common_type&l=
t;R...>::type.</div><div><br></div><div>itaj<br></div><div><br></div><di=
v>On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:<br></div=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyo=
ne,=C2=A0<div>Is there any proposal floating regarding returning an uniniti=
alized optional?</div><div><br></div><div>I'm referring to the followin=
g functions:</div><div><br></div><div><div>std::optional<int> get1()<=
/div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =3D =
make_optional<int>(4);</div><div><span style=3D"white-space:pre"> </s=
pan>if (opt.has_value()) return opt;</div><div><span style=3D"white-space:p=
re"> </span>return std::nullopt;</div><div>}</div><div><br></div><div>auto =
get2()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto o=
pt =3D make_optional<int>(4);</div><div><span style=3D"white-space:pr=
e"> </span>if (opt.has_value()) return opt;</div><div><span style=3D"white-=
space:pre"> </span>return std::nullopt;</div><div>}</div><div><br></div><di=
v>std::optional<int> get3()</div><div>{</div><div><span style=3D"whit=
e-space:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><s=
pan style=3D"white-space:pre"> </span>return (opt.has_value() ? opt.value()=
: std::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>=
The first one compiles, but the second one does not (auto cannot simply ded=
uce the type of nullopt, as it's basically an {} )</div><div>The third =
one is also something that I'd expect to be able to do, but the compile=
r does not allow unary return of such kind.</div><div><br></div><div>All th=
e best,</div><div>Robert</div><div><br></div></div></blockquote></div></div=
></blockquote></div></div></blockquote></div></div></blockquote></div></div=
></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/de619d9b-2bcd-4ed0-84f5-3e7d631a3dd4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/de619d9b-2bcd-4ed0-84f5-3e7d631a3dd4=
%40isocpp.org</a>.<br />
------=_Part_1067_542738280.1542368652707--
------=_Part_1066_1942040189.1542368652706--
.
Author: mihailnajdenov@gmail.com
Date: Fri, 16 Nov 2018 05:12:27 -0800 (PST)
Raw View
------=_Part_1100_741522806.1542373947823
Content-Type: multipart/alternative;
boundary="----=_Part_1101_1259193695.1542373947824"
------=_Part_1101_1259193695.1542373947824
Content-Type: text/plain; charset="UTF-8"
Note that the issue has nothing to do with lifetime.
using common_type could also lead to slicing
struct A {};
struct B : A {};
auto func()
{
if(something)
return std::common_type_t<A, B>(A{});
return std::common_type_t<A, B>(B{});
}
Ultimately the issue is about having "type promotion" - right now even
integer promotion does not work - which will require completely new
extension points for custom types, incl. optional.
It is a different story if the are really willing to give auto return type
such powers.
Auto here is used as a declaration and we want to know what the declaration
is - what the returned type is.
Right now, when we read a function we can "early out" and any return
statement will answer our questions. If we allow proportion, all bets are
off
- any return can be a promoting one and we might not even notice it..
On Friday, November 16, 2018 at 1:44:12 PM UTC+2, Itaj Sherman wrote:
>
> and constructors like
> string_view::string_view( std::string const& )
>
> which are not marked with the 'explicit' keywords, because they are useful
> in many implicit cases,
> could be marked with a new keyword 'instable' to set stably_convertible to
> false.
>
> On Friday, 16 November 2018 13:40:11 UTC+2, Itaj Sherman wrote:
>>
>> Probably more cases could improve safety. The following syntaxes also
>> allow any implicit conversion, and might benefit from only allowing
>> stably_convertible ones:
>>
>> T x = EXPRESSION_WITH_TEMPORARY_RESULT;
>>
>> T foo() { return EXPRESSION_WITH_TEMPORARY_RESULT; }
>>
>>
>> On Friday, 16 November 2018 13:19:21 UTC+2, Itaj Sherman wrote:
>>>
>>>
>>> Yeah, true.
>>>
>>> It will require some sort of is_stable_valid<T> trait that says a type
>>> can be safely returned because it doesn't depend on non-owned addresses.
>>>
>>> so value types and owner-pointers can be is_stable_valid<T>, while
>>> observer pointers, iterators and views cannot.
>>> wrappers like optional, variant, tuple will be is_stable_valid if all
>>> their elements are.
>>>
>>> if auto function has different return types is can return
>>> enable_if_stable_valid_t< commot_type_t<R...> >
>>> template< typename T > using enable_if_stable_valid_t = enable_if<
>>> is_stable_valid<T>, T >::type;
>>>
>>>
>>> an even more generalized notion would be:
>>>
>>> is_stably_convertible< S, R >
>>> which will specify that is_convertible< S, R >, and that the resulting R
>>> is no less stable than S.
>>> and define stably_common_type_t< R... > based on is_stably_convertible.
>>>
>>> formally:
>>> define the instability-set of and object X as the set of objects whose
>>> lifetime X doesn't own, but still requires them to be alive for X's
>>> contract - depending on the user to make sure they stay alive.
>>>
>>> and is_stably_convertible< S, R > means that
>>> 1 - the instability set of the resulting R is contained within the
>>> instability set of the source S
>>> 2 - resulting R doesn't own any objects from the instability set of S
>>> (that is it doesn't initiate ownership on it).
>>>
>>> so basically if is_stable_valid<T> then instability set is empty.
>>> T* x = &a; //instability set is {a}
>>> T** y = &x; //instability set is {x,a}
>>> std::variant<int, T*> z = x; //instability set is {a}
>>>
>>> basically:
>>> is_stably_convertible< T, optional<T> > == true
>>> is_stably_convertible< T*, optional<T*> > == true
>>> is_stably_convertible< string, string_view > == false
>>> is_stably_convertible< string_view, string > == true
>>> is_stably_convertible< shared_ptr/unique_ptr, T* > == false //both
>>> because the conversion is not implicit, and even if it were, the
>>> instability set of the result is bigger.
>>> is_stably_convertible< T*, shared_ptr/unique_ptr > == false //both
>>> because the conversion is not implicit, and even if it were, it would take
>>> ownership on the unowned.
>>>
>>> this can also improve safety with the extended lifetime of temporary
>>> bounded to reference:
>>>
>>> T& = expression; //if expression is temporary, will require
>>> is_stably_convertible< typeof(expression), T >, otherwise ill-formed.
>>>
>>> itaj
>>>
>>> On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.com wrote:
>>>>
>>>> Naaaah
>>>>
>>>> auto func()
>>>> {
>>>> if(something)
>>>> return std::common_type_t<std::string_view,
>>>> std::string>(std::string_view("sds"));
>>>>
>>>> return std::common_type_t<std::string_view,
>>>> std::string>(std::string("sds"));
>>>> }
>>>>
>>>> Boom.
>>>>
>>>>
>>>> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>>>>
>>>>>
>>>>> I disagree with the other responds. I actually think you have a point.
>>>>>
>>>>> nullopt and optional<int> are not totally "unrelated", specifically
>>>>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>>>>
>>>>> Suppose you have a function with several return statements returning
>>>>> type R1..Rn.
>>>>> The currently rules of auto return deduction is they all have to be
>>>>> the same type, and it will be deduced.
>>>>> But another reasonable option could have been that the deduced return
>>>>> type will be std::common_type<R...>::type.
>>>>>
>>>>> itaj
>>>>>
>>>>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>> Is there any proposal floating regarding returning an uninitialized
>>>>>> optional?
>>>>>>
>>>>>> I'm referring to the following functions:
>>>>>>
>>>>>> std::optional<int> get1()
>>>>>> {
>>>>>> auto opt = make_optional<int>(4);
>>>>>> if (opt.has_value()) return opt;
>>>>>> return std::nullopt;
>>>>>> }
>>>>>>
>>>>>> auto get2()
>>>>>> {
>>>>>> auto opt = make_optional<int>(4);
>>>>>> if (opt.has_value()) return opt;
>>>>>> return std::nullopt;
>>>>>> }
>>>>>>
>>>>>> std::optional<int> get3()
>>>>>> {
>>>>>> auto opt = make_optional<int>(4);
>>>>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> The first one compiles, but the second one does not (auto cannot
>>>>>> simply deduce the type of nullopt, as it's basically an {} )
>>>>>> The third one is also something that I'd expect to be able to do, but
>>>>>> the compiler does not allow unary return of such kind.
>>>>>>
>>>>>> All the best,
>>>>>> Robert
>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c08b0754-87ff-4bbb-9b34-c457b2b64ece%40isocpp.org.
------=_Part_1101_1259193695.1542373947824
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Note that the issue has nothing to do with lifetime.<div>u=
sing common_type could also lead to slicing</div><div><br></div><div>struct=
A {};</div><div>struct B : A {};</div><div><br></div><div>auto func()</div=
><div>{</div><div>=C2=A0 =C2=A0 if(something)</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 return std::common_type_t<A, B>(A{});</div><div>=C2=A0 =C2=
=A0 return=C2=A0 std::common_type_t<A, B>(B{});</div><div>}=C2=A0<br>=
<br>Ultimately the issue is about having "type promotion"=C2=A0 -=
=C2=A0 right now even integer promotion does not work - which will require =
completely new extension points for custom types, incl. optional.</div><div=
><br></div><div>It is a different story if the are really willing to give a=
uto return type such powers.=C2=A0</div><div>Auto here is used as a declara=
tion and we want to know what the declaration is - what the returned type i=
s.</div><div>Right now, when we read a function we can "early out"=
; and any return statement will answer our questions. If we allow proportio=
n, all bets are off=C2=A0</div><div>-=C2=A0 any return can be a promoting o=
ne and we might not even notice it..=C2=A0</div><div><br></div><br>On Frida=
y, November 16, 2018 at 1:44:12 PM UTC+2, Itaj Sherman wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">and constructors like=C2=A0=
<div>string_view::string_view( std::string const& )</div><div><br></div=
><div>which are not marked with the 'explicit' keywords, because th=
ey are useful in many implicit cases,</div><div>could be marked with a new =
keyword 'instable' to set stably_convertible to false.<br><br>On Fr=
iday, 16 November 2018 13:40:11 UTC+2, Itaj Sherman wrote:<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">Probably more cases could improve =
safety. The following syntaxes also allow any implicit conversion, and migh=
t benefit from only allowing stably_convertible ones:<br><br>T x =3D EXPRES=
SION_WITH_TEMPORARY_<wbr>RESULT;<div><br></div><div>T foo() { return EXPRES=
SION_WITH_TEMPORARY_<wbr>RESULT; }</div><div><br></div><div><br></div><div>=
On Friday, 16 November 2018 13:19:21 UTC+2, Itaj Sherman wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Yeah, true.<br><br>It wil=
l require some sort of is_stable_valid<T> trait that says a type can =
be safely returned because it doesn't depend on non-owned addresses.<br=
><div><br></div><div>so value types and owner-pointers can be is_stable_val=
id<T>, while observer pointers, iterators and views cannot.</div><div=
>wrappers like optional, variant, tuple will be is_stable_valid if all thei=
r elements are.</div><div><br></div><div>if auto function has different ret=
urn types is can return enable_if_stable_valid_t< commot_type_t<R...&=
gt; ><br></div><div>template< typename T > using enable_if_stable_=
valid_t =3D enable_if< is_stable_valid<T>, T >::type;<br></div>=
<div><br></div><div><br></div><div>an even more generalized notion would be=
:</div><div><br></div><div><div>is_stably_convertible< S, R ></div><d=
iv>which will specify that is_convertible< S, R >, and that the resul=
ting R is no less stable than S.</div><div>and define stably_common_type_t&=
lt; R... > based on is_stably_convertible.<br><br>formally:</div></div><=
div>define the instability-set of and object X as the set of objects whose =
lifetime X doesn't own, but still requires them to be alive for X's=
contract - depending on the user to make sure they stay alive.</div><div><=
br></div><div><div>and is_stably_convertible< S, R > means that=C2=A0=
</div><div>1 - the instability set of the resulting R is contained within t=
he instability set of the source S</div><div>2 - resulting R doesn't ow=
n any objects from the instability set of S (that is it doesn't initiat=
e ownership on it).</div></div><div><br></div><div>so basically if is_stabl=
e_valid<T> then instability set is empty.<br></div><div>T* x =3D &=
;a; //instability set is {a}</div><div>T** y =3D &x; //instability set =
is {x,a}</div><div>std::variant<int, T*> z =3D x; //instability set i=
s {a}</div><div><br></div><div>basically:<br></div><div>is_stably_convertib=
le< T, optional<T> > =3D=3D true</div><div></div><div>is_stably=
_convertible< T*, optional<T*> > =3D=3D true</div><div><div>is_=
stably_convertible< string, string_view > =3D=3D false<br></div></div=
><div><div>is_stably_convertible< string_view, string > =3D=3D true<b=
r></div></div><div><div>is_stably_convertible< shared_ptr/unique_ptr, T*=
> =3D=3D false //both because the conversion is not implicit, and even =
if it were, the instability set of the result is bigger.<br></div></div><di=
v>is_stably_convertible< T*, shared_ptr/unique_ptr > =3D=3D false //b=
oth because the conversion is not implicit, and even if it were, it would t=
ake ownership on the unowned.<br></div><div><br></div><div>this can also im=
prove safety with the extended lifetime of temporary bounded to reference:<=
br><br>T& =3D expression; //if expression is temporary, will require is=
_stably_convertible< typeof(expression), T >, otherwise ill-formed.</=
div><div><br></div><div>itaj</div><div><br>On Friday, 16 November 2018 10:5=
7:03 UTC+2, <a>mihailn...@gmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">Naaaah<div><br></div><div><div><font face=3D"c=
ourier new, monospace">auto func()</font></div><div><font face=3D"courier n=
ew, monospace">{</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 if(something)</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::common_type_t<std::<wbr>str=
ing_view, std::string>(std::string_view(<wbr>"sds"));</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=C2=A0</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 return std::co=
mmon_type_t<std::<wbr>string_view, std::string>(std::string("sds=
"<wbr>));</font></div><div><font face=3D"courier new, monospace">}</fo=
nt></div></div><div><br>Boom.</div><div><br><br>On Friday, November 16, 201=
8 at 2:42:26 AM UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><br>I disagree with the other responds. I actually =
think you have a point.<br><br><div>nullopt and optional<int> are not=
totally "unrelated", specifically std::common_type< nullopt, =
optional<int> >::type =3D=3D=3D optional<int>.</div><div><br=
></div><div>Suppose you have a function with several return statements retu=
rning type R1..Rn.<br></div><div>The currently rules of auto return deducti=
on is they all have to be the same type, and it will be deduced.</div><div>=
But another reasonable option could have been that the deduced return type =
will be std::common_type<R...>::type.</div><div><br></div><div>itaj<b=
r></div><div><br></div><div>On Monday, 12 November 2018 08:18:59 UTC+2, rob=
ert badea wrote:<br></div><div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">Hello everyone,=C2=A0<div>Is there any proposal floating rega=
rding returning an uninitialized optional?</div><div><br></div><div>I'm=
referring to the following functions:</div><div><br></div><div><div>std::o=
ptional<int> get1()</div><div>{</div><div><span style=3D"white-space:=
pre"> </span>auto opt =3D make_optional<int>(4);</div><div><span styl=
e=3D"white-space:pre"> </span>if (opt.has_value()) return opt;</div><div><s=
pan style=3D"white-space:pre"> </span>return std::nullopt;</div><div>}</div=
><div><br></div><div>auto get2()</div><div>{</div><div><span style=3D"white=
-space:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><sp=
an style=3D"white-space:pre"> </span>if (opt.has_value()) return opt;</div>=
<div><span style=3D"white-space:pre"> </span>return std::nullopt;</div><div=
>}</div><div><br></div><div>std::optional<int> get3()</div><div>{</di=
v><div><span style=3D"white-space:pre"> </span>auto opt =3D make_optional&l=
t;int>(4);</div><div><span style=3D"white-space:pre"> </span>return (opt=
..has_value() ? opt.value() : std::nullopt;</div><div>}</div><div><br></div>=
</div><div><br></div><div>The first one compiles, but the second one does n=
ot (auto cannot simply deduce the type of nullopt, as it's basically an=
{} )</div><div>The third one is also something that I'd expect to be a=
ble to do, but the compiler does not allow unary return of such kind.</div>=
<div><br></div><div>All the best,</div><div>Robert</div><div><br></div></di=
v></blockquote></div></div></blockquote></div></div></blockquote></div></di=
v></blockquote></div></div></blockquote></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c08b0754-87ff-4bbb-9b34-c457b2b64ece%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c08b0754-87ff-4bbb-9b34-c457b2b64ece=
%40isocpp.org</a>.<br />
------=_Part_1101_1259193695.1542373947824--
------=_Part_1100_741522806.1542373947823--
.
Author: Itaj Sherman <itajsherman@gmail.com>
Date: Fri, 16 Nov 2018 06:30:04 -0800 (PST)
Raw View
------=_Part_1186_382255186.1542378604874
Content-Type: multipart/alternative;
boundary="----=_Part_1187_259175675.1542378604875"
------=_Part_1187_259175675.1542378604875
Content-Type: text/plain; charset="UTF-8"
Well, I totally see your point about slicing.
And I should have add to the requirement of what I called
is_stably_convertible, that derived to base is not allowed, and that
numeric narrowing are not allowed.
Basically everything should allow the Result to be used instead of the
Source.
But ultimately in the case of string to string_view, and the other cases I
mentioned, the underlying problem is that the Result depends on the
Source's lifetime.
Is what you mean about "promotion", that you consider string to string_view
an implicit cast but not a promotion?
And then you say that the name of is_stably_convertible should be
is_promotable.
Either way, the OP has a very reasonable point, and the right thing to do
is explain what would be needed to solve it rather than just telling them
it's not possible.
itaj
On Friday, 16 November 2018 15:12:27 UTC+2, mihailn...@gmail.com wrote:
>
> Note that the issue has nothing to do with lifetime.
> using common_type could also lead to slicing
>
> struct A {};
> struct B : A {};
>
> auto func()
> {
> if(something)
> return std::common_type_t<A, B>(A{});
> return std::common_type_t<A, B>(B{});
> }
>
> Ultimately the issue is about having "type promotion" - right now even
> integer promotion does not work - which will require completely new
> extension points for custom types, incl. optional.
>
> It is a different story if the are really willing to give auto return type
> such powers.
> Auto here is used as a declaration and we want to know what the
> declaration is - what the returned type is.
> Right now, when we read a function we can "early out" and any return
> statement will answer our questions. If we allow proportion, all bets are
> off
> - any return can be a promoting one and we might not even notice it..
>
>
> On Friday, November 16, 2018 at 1:44:12 PM UTC+2, Itaj Sherman wrote:
>>
>> and constructors like
>> string_view::string_view( std::string const& )
>>
>> which are not marked with the 'explicit' keywords, because they are
>> useful in many implicit cases,
>> could be marked with a new keyword 'instable' to set stably_convertible
>> to false.
>>
>> On Friday, 16 November 2018 13:40:11 UTC+2, Itaj Sherman wrote:
>>>
>>> Probably more cases could improve safety. The following syntaxes also
>>> allow any implicit conversion, and might benefit from only allowing
>>> stably_convertible ones:
>>>
>>> T x = EXPRESSION_WITH_TEMPORARY_RESULT;
>>>
>>> T foo() { return EXPRESSION_WITH_TEMPORARY_RESULT; }
>>>
>>>
>>> On Friday, 16 November 2018 13:19:21 UTC+2, Itaj Sherman wrote:
>>>>
>>>>
>>>> Yeah, true.
>>>>
>>>> It will require some sort of is_stable_valid<T> trait that says a type
>>>> can be safely returned because it doesn't depend on non-owned addresses.
>>>>
>>>> so value types and owner-pointers can be is_stable_valid<T>, while
>>>> observer pointers, iterators and views cannot.
>>>> wrappers like optional, variant, tuple will be is_stable_valid if all
>>>> their elements are.
>>>>
>>>> if auto function has different return types is can return
>>>> enable_if_stable_valid_t< commot_type_t<R...> >
>>>> template< typename T > using enable_if_stable_valid_t = enable_if<
>>>> is_stable_valid<T>, T >::type;
>>>>
>>>>
>>>> an even more generalized notion would be:
>>>>
>>>> is_stably_convertible< S, R >
>>>> which will specify that is_convertible< S, R >, and that the resulting
>>>> R is no less stable than S.
>>>> and define stably_common_type_t< R... > based on is_stably_convertible.
>>>>
>>>> formally:
>>>> define the instability-set of and object X as the set of objects whose
>>>> lifetime X doesn't own, but still requires them to be alive for X's
>>>> contract - depending on the user to make sure they stay alive.
>>>>
>>>> and is_stably_convertible< S, R > means that
>>>> 1 - the instability set of the resulting R is contained within the
>>>> instability set of the source S
>>>> 2 - resulting R doesn't own any objects from the instability set of S
>>>> (that is it doesn't initiate ownership on it).
>>>>
>>>> so basically if is_stable_valid<T> then instability set is empty.
>>>> T* x = &a; //instability set is {a}
>>>> T** y = &x; //instability set is {x,a}
>>>> std::variant<int, T*> z = x; //instability set is {a}
>>>>
>>>> basically:
>>>> is_stably_convertible< T, optional<T> > == true
>>>> is_stably_convertible< T*, optional<T*> > == true
>>>> is_stably_convertible< string, string_view > == false
>>>> is_stably_convertible< string_view, string > == true
>>>> is_stably_convertible< shared_ptr/unique_ptr, T* > == false //both
>>>> because the conversion is not implicit, and even if it were, the
>>>> instability set of the result is bigger.
>>>> is_stably_convertible< T*, shared_ptr/unique_ptr > == false //both
>>>> because the conversion is not implicit, and even if it were, it would take
>>>> ownership on the unowned.
>>>>
>>>> this can also improve safety with the extended lifetime of temporary
>>>> bounded to reference:
>>>>
>>>> T& = expression; //if expression is temporary, will require
>>>> is_stably_convertible< typeof(expression), T >, otherwise ill-formed.
>>>>
>>>> itaj
>>>>
>>>> On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.com wrote:
>>>>>
>>>>> Naaaah
>>>>>
>>>>> auto func()
>>>>> {
>>>>> if(something)
>>>>> return std::common_type_t<std::string_view,
>>>>> std::string>(std::string_view("sds"));
>>>>>
>>>>> return std::common_type_t<std::string_view,
>>>>> std::string>(std::string("sds"));
>>>>> }
>>>>>
>>>>> Boom.
>>>>>
>>>>>
>>>>> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>>>>>
>>>>>>
>>>>>> I disagree with the other responds. I actually think you have a point.
>>>>>>
>>>>>> nullopt and optional<int> are not totally "unrelated", specifically
>>>>>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>>>>>
>>>>>> Suppose you have a function with several return statements returning
>>>>>> type R1..Rn.
>>>>>> The currently rules of auto return deduction is they all have to be
>>>>>> the same type, and it will be deduced.
>>>>>> But another reasonable option could have been that the deduced return
>>>>>> type will be std::common_type<R...>::type.
>>>>>>
>>>>>> itaj
>>>>>>
>>>>>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>>>>>
>>>>>>> Hello everyone,
>>>>>>> Is there any proposal floating regarding returning an uninitialized
>>>>>>> optional?
>>>>>>>
>>>>>>> I'm referring to the following functions:
>>>>>>>
>>>>>>> std::optional<int> get1()
>>>>>>> {
>>>>>>> auto opt = make_optional<int>(4);
>>>>>>> if (opt.has_value()) return opt;
>>>>>>> return std::nullopt;
>>>>>>> }
>>>>>>>
>>>>>>> auto get2()
>>>>>>> {
>>>>>>> auto opt = make_optional<int>(4);
>>>>>>> if (opt.has_value()) return opt;
>>>>>>> return std::nullopt;
>>>>>>> }
>>>>>>>
>>>>>>> std::optional<int> get3()
>>>>>>> {
>>>>>>> auto opt = make_optional<int>(4);
>>>>>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> The first one compiles, but the second one does not (auto cannot
>>>>>>> simply deduce the type of nullopt, as it's basically an {} )
>>>>>>> The third one is also something that I'd expect to be able to do,
>>>>>>> but the compiler does not allow unary return of such kind.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Robert
>>>>>>>
>>>>>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f1e8be7e-2246-4867-bd38-cf94f7a40fc7%40isocpp.org.
------=_Part_1187_259175675.1542378604875
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well, I totally see your point about slicing.<br>And I sho=
uld have add to the requirement of what I called is_stably_convertible, tha=
t derived to base is not allowed, and that numeric narrowing are not allowe=
d.<br>Basically everything should allow the Result to be used instead of th=
e Source.<br><br>But ultimately in the case of string to string_view, and t=
he other cases I mentioned, the underlying problem is that the Result depen=
ds on the Source's lifetime.<br><br>Is what you mean about "promot=
ion", that you consider string to string_view an implicit cast but not=
a promotion?<br>And then you say that the name of is_stably_convertible sh=
ould be is_promotable.<br><br>Either way, the OP has a very reasonable poin=
t, and the right thing to do is explain what would be needed to solve it ra=
ther than just telling them it's not possible.<div><br></div><div>itaj<=
br><br>On Friday, 16 November 2018 15:12:27 UTC+2, mihailn...@gmail.com wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Note that=
the issue has nothing to do with lifetime.<div>using common_type could als=
o lead to slicing</div><div><br></div><div>struct A {};</div><div>struct B =
: A {};</div><div><br></div><div>auto func()</div><div>{</div><div>=C2=A0 =
=C2=A0 if(something)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::comm=
on_type_t<A, B>(A{});</div><div>=C2=A0 =C2=A0 return=C2=A0 std::commo=
n_type_t<A, B>(B{});</div><div>}=C2=A0<br><br>Ultimately the issue is=
about having "type promotion"=C2=A0 -=C2=A0 right now even integ=
er promotion does not work - which will require completely new extension po=
ints for custom types, incl. optional.</div><div><br></div><div>It is a dif=
ferent story if the are really willing to give auto return type such powers=
..=C2=A0</div><div>Auto here is used as a declaration and we want to know wh=
at the declaration is - what the returned type is.</div><div>Right now, whe=
n we read a function we can "early out" and any return statement =
will answer our questions. If we allow proportion, all bets are off=C2=A0</=
div><div>-=C2=A0 any return can be a promoting one and we might not even no=
tice it..=C2=A0</div><div><br></div><br>On Friday, November 16, 2018 at 1:4=
4:12 PM UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">and constructors like=C2=A0<div>string_view::string_view(=
std::string const& )</div><div><br></div><div>which are not marked wit=
h the 'explicit' keywords, because they are useful in many implicit=
cases,</div><div>could be marked with a new keyword 'instable' to =
set stably_convertible to false.<br><br>On Friday, 16 November 2018 13:40:1=
1 UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Probably more cases could improve safety. The following syntaxes=
also allow any implicit conversion, and might benefit from only allowing s=
tably_convertible ones:<br><br>T x =3D EXPRESSION_WITH_TEMPORARY_<wbr>RESUL=
T;<div><br></div><div>T foo() { return EXPRESSION_WITH_TEMPORARY_<wbr>RESUL=
T; }</div><div><br></div><div><br></div><div>On Friday, 16 November 2018 13=
:19:21 UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br>Yeah, true.<br><br>It will require some sort of is_st=
able_valid<T> trait that says a type can be safely returned because i=
t doesn't depend on non-owned addresses.<br><div><br></div><div>so valu=
e types and owner-pointers can be is_stable_valid<T>, while observer =
pointers, iterators and views cannot.</div><div>wrappers like optional, var=
iant, tuple will be is_stable_valid if all their elements are.</div><div><b=
r></div><div>if auto function has different return types is can return enab=
le_if_stable_valid_t< commot_type_t<R...> ><br></div><div>templ=
ate< typename T > using enable_if_stable_valid_t =3D enable_if< is=
_stable_valid<T>, T >::type;<br></div><div><br></div><div><br></di=
v><div>an even more generalized notion would be:</div><div><br></div><div><=
div>is_stably_convertible< S, R ></div><div>which will specify that i=
s_convertible< S, R >, and that the resulting R is no less stable tha=
n S.</div><div>and define stably_common_type_t< R... > based on is_st=
ably_convertible.<br><br>formally:</div></div><div>define the instability-s=
et of and object X as the set of objects whose lifetime X doesn't own, =
but still requires them to be alive for X's contract - depending on the=
user to make sure they stay alive.</div><div><br></div><div><div>and is_st=
ably_convertible< S, R > means that=C2=A0</div><div>1 - the instabili=
ty set of the resulting R is contained within the instability set of the so=
urce S</div><div>2 - resulting R doesn't own any objects from the insta=
bility set of S (that is it doesn't initiate ownership on it).</div></d=
iv><div><br></div><div>so basically if is_stable_valid<T> then instab=
ility set is empty.<br></div><div>T* x =3D &a; //instability set is {a}=
</div><div>T** y =3D &x; //instability set is {x,a}</div><div>std::vari=
ant<int, T*> z =3D x; //instability set is {a}</div><div><br></div><d=
iv>basically:<br></div><div>is_stably_convertible< T, optional<T> =
> =3D=3D true</div><div></div><div>is_stably_convertible< T*, optiona=
l<T*> > =3D=3D true</div><div><div>is_stably_convertible< strin=
g, string_view > =3D=3D false<br></div></div><div><div>is_stably_convert=
ible< string_view, string > =3D=3D true<br></div></div><div><div>is_s=
tably_convertible< shared_ptr/unique_ptr, T* > =3D=3D false //both be=
cause the conversion is not implicit, and even if it were, the instability =
set of the result is bigger.<br></div></div><div>is_stably_convertible< =
T*, shared_ptr/unique_ptr > =3D=3D false //both because the conversion i=
s not implicit, and even if it were, it would take ownership on the unowned=
..<br></div><div><br></div><div>this can also improve safety with the extend=
ed lifetime of temporary bounded to reference:<br><br>T& =3D expression=
; //if expression is temporary, will require is_stably_convertible< type=
of(expression), T >, otherwise ill-formed.</div><div><br></div><div>itaj=
</div><div><br>On Friday, 16 November 2018 10:57:03 UTC+2, <a>mihailn...@gm=
ail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>Naaaah<div><br></div><div><div><font face=3D"courier new, monospace">auto =
func()</font></div><div><font face=3D"courier new, monospace">{</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if(something)</fo=
nt></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return std::common_type_t<std::<wbr>string_view, std::string>(=
std::string_view(<wbr>"sds"));</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"cou=
rier new, monospace">=C2=A0 =C2=A0 return std::common_type_t<std::<wbr>s=
tring_view, std::string>(std::string("sds"<wbr>));</font></div=
><div><font face=3D"courier new, monospace">}</font></div></div><div><br>Bo=
om.</div><div><br><br>On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Ita=
j Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r>I disagree with the other responds. I actually think you have a point.<br=
><br><div>nullopt and optional<int> are not totally "unrelated&q=
uot;, specifically std::common_type< nullopt, optional<int> >::=
type =3D=3D=3D optional<int>.</div><div><br></div><div>Suppose you ha=
ve a function with several return statements returning type R1..Rn.<br></di=
v><div>The currently rules of auto return deduction is they all have to be =
the same type, and it will be deduced.</div><div>But another reasonable opt=
ion could have been that the deduced return type will be std::common_type&l=
t;R...>::type.</div><div><br></div><div>itaj<br></div><div><br></div><di=
v>On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:<br></div=
><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyo=
ne,=C2=A0<div>Is there any proposal floating regarding returning an uniniti=
alized optional?</div><div><br></div><div>I'm referring to the followin=
g functions:</div><div><br></div><div><div>std::optional<int> get1()<=
/div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =3D =
make_optional<int>(4);</div><div><span style=3D"white-space:pre"> </s=
pan>if (opt.has_value()) return opt;</div><div><span style=3D"white-space:p=
re"> </span>return std::nullopt;</div><div>}</div><div><br></div><div>auto =
get2()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto o=
pt =3D make_optional<int>(4);</div><div><span style=3D"white-space:pr=
e"> </span>if (opt.has_value()) return opt;</div><div><span style=3D"white-=
space:pre"> </span>return std::nullopt;</div><div>}</div><div><br></div><di=
v>std::optional<int> get3()</div><div>{</div><div><span style=3D"whit=
e-space:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><s=
pan style=3D"white-space:pre"> </span>return (opt.has_value() ? opt.value()=
: std::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>=
The first one compiles, but the second one does not (auto cannot simply ded=
uce the type of nullopt, as it's basically an {} )</div><div>The third =
one is also something that I'd expect to be able to do, but the compile=
r does not allow unary return of such kind.</div><div><br></div><div>All th=
e best,</div><div>Robert</div><div><br></div></div></blockquote></div></div=
></blockquote></div></div></blockquote></div></div></blockquote></div></div=
></blockquote></div></div></blockquote></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f1e8be7e-2246-4867-bd38-cf94f7a40fc7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1e8be7e-2246-4867-bd38-cf94f7a40fc7=
%40isocpp.org</a>.<br />
------=_Part_1187_259175675.1542378604875--
------=_Part_1186_382255186.1542378604874--
.
Author: Itaj Sherman <itajsherman@gmail.com>
Date: Fri, 16 Nov 2018 06:54:49 -0800 (PST)
Raw View
------=_Part_1168_283770705.1542380090046
Content-Type: multipart/alternative;
boundary="----=_Part_1169_762408317.1542380090047"
------=_Part_1169_762408317.1542380090047
Content-Type: text/plain; charset="UTF-8"
all that said, are there any proposals that try to resolve these issues?
On Friday, 16 November 2018 16:30:05 UTC+2, Itaj Sherman wrote:
>
> Well, I totally see your point about slicing.
> And I should have add to the requirement of what I called
> is_stably_convertible, that derived to base is not allowed, and that
> numeric narrowing are not allowed.
> Basically everything should allow the Result to be used instead of the
> Source.
>
> But ultimately in the case of string to string_view, and the other cases I
> mentioned, the underlying problem is that the Result depends on the
> Source's lifetime.
>
> Is what you mean about "promotion", that you consider string to
> string_view an implicit cast but not a promotion?
> And then you say that the name of is_stably_convertible should be
> is_promotable.
>
> Either way, the OP has a very reasonable point, and the right thing to do
> is explain what would be needed to solve it rather than just telling them
> it's not possible.
>
> itaj
>
> On Friday, 16 November 2018 15:12:27 UTC+2, mihailn...@gmail.com wrote:
>>
>> Note that the issue has nothing to do with lifetime.
>> using common_type could also lead to slicing
>>
>> struct A {};
>> struct B : A {};
>>
>> auto func()
>> {
>> if(something)
>> return std::common_type_t<A, B>(A{});
>> return std::common_type_t<A, B>(B{});
>> }
>>
>> Ultimately the issue is about having "type promotion" - right now even
>> integer promotion does not work - which will require completely new
>> extension points for custom types, incl. optional.
>>
>> It is a different story if the are really willing to give auto return
>> type such powers.
>> Auto here is used as a declaration and we want to know what the
>> declaration is - what the returned type is.
>> Right now, when we read a function we can "early out" and any return
>> statement will answer our questions. If we allow proportion, all bets are
>> off
>> - any return can be a promoting one and we might not even notice it..
>>
>>
>> On Friday, November 16, 2018 at 1:44:12 PM UTC+2, Itaj Sherman wrote:
>>>
>>> and constructors like
>>> string_view::string_view( std::string const& )
>>>
>>> which are not marked with the 'explicit' keywords, because they are
>>> useful in many implicit cases,
>>> could be marked with a new keyword 'instable' to set stably_convertible
>>> to false.
>>>
>>> On Friday, 16 November 2018 13:40:11 UTC+2, Itaj Sherman wrote:
>>>>
>>>> Probably more cases could improve safety. The following syntaxes also
>>>> allow any implicit conversion, and might benefit from only allowing
>>>> stably_convertible ones:
>>>>
>>>> T x = EXPRESSION_WITH_TEMPORARY_RESULT;
>>>>
>>>> T foo() { return EXPRESSION_WITH_TEMPORARY_RESULT; }
>>>>
>>>>
>>>> On Friday, 16 November 2018 13:19:21 UTC+2, Itaj Sherman wrote:
>>>>>
>>>>>
>>>>> Yeah, true.
>>>>>
>>>>> It will require some sort of is_stable_valid<T> trait that says a type
>>>>> can be safely returned because it doesn't depend on non-owned addresses.
>>>>>
>>>>> so value types and owner-pointers can be is_stable_valid<T>, while
>>>>> observer pointers, iterators and views cannot.
>>>>> wrappers like optional, variant, tuple will be is_stable_valid if all
>>>>> their elements are.
>>>>>
>>>>> if auto function has different return types is can return
>>>>> enable_if_stable_valid_t< commot_type_t<R...> >
>>>>> template< typename T > using enable_if_stable_valid_t = enable_if<
>>>>> is_stable_valid<T>, T >::type;
>>>>>
>>>>>
>>>>> an even more generalized notion would be:
>>>>>
>>>>> is_stably_convertible< S, R >
>>>>> which will specify that is_convertible< S, R >, and that the resulting
>>>>> R is no less stable than S.
>>>>> and define stably_common_type_t< R... > based on is_stably_convertible.
>>>>>
>>>>> formally:
>>>>> define the instability-set of and object X as the set of objects whose
>>>>> lifetime X doesn't own, but still requires them to be alive for X's
>>>>> contract - depending on the user to make sure they stay alive.
>>>>>
>>>>> and is_stably_convertible< S, R > means that
>>>>> 1 - the instability set of the resulting R is contained within the
>>>>> instability set of the source S
>>>>> 2 - resulting R doesn't own any objects from the instability set of S
>>>>> (that is it doesn't initiate ownership on it).
>>>>>
>>>>> so basically if is_stable_valid<T> then instability set is empty.
>>>>> T* x = &a; //instability set is {a}
>>>>> T** y = &x; //instability set is {x,a}
>>>>> std::variant<int, T*> z = x; //instability set is {a}
>>>>>
>>>>> basically:
>>>>> is_stably_convertible< T, optional<T> > == true
>>>>> is_stably_convertible< T*, optional<T*> > == true
>>>>> is_stably_convertible< string, string_view > == false
>>>>> is_stably_convertible< string_view, string > == true
>>>>> is_stably_convertible< shared_ptr/unique_ptr, T* > == false //both
>>>>> because the conversion is not implicit, and even if it were, the
>>>>> instability set of the result is bigger.
>>>>> is_stably_convertible< T*, shared_ptr/unique_ptr > == false //both
>>>>> because the conversion is not implicit, and even if it were, it would take
>>>>> ownership on the unowned.
>>>>>
>>>>> this can also improve safety with the extended lifetime of temporary
>>>>> bounded to reference:
>>>>>
>>>>> T& = expression; //if expression is temporary, will require
>>>>> is_stably_convertible< typeof(expression), T >, otherwise ill-formed.
>>>>>
>>>>> itaj
>>>>>
>>>>> On Friday, 16 November 2018 10:57:03 UTC+2, mihailn...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> Naaaah
>>>>>>
>>>>>> auto func()
>>>>>> {
>>>>>> if(something)
>>>>>> return std::common_type_t<std::string_view,
>>>>>> std::string>(std::string_view("sds"));
>>>>>>
>>>>>> return std::common_type_t<std::string_view,
>>>>>> std::string>(std::string("sds"));
>>>>>> }
>>>>>>
>>>>>> Boom.
>>>>>>
>>>>>>
>>>>>> On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sherman wrote:
>>>>>>>
>>>>>>>
>>>>>>> I disagree with the other responds. I actually think you have a
>>>>>>> point.
>>>>>>>
>>>>>>> nullopt and optional<int> are not totally "unrelated", specifically
>>>>>>> std::common_type< nullopt, optional<int> >::type === optional<int>.
>>>>>>>
>>>>>>> Suppose you have a function with several return statements returning
>>>>>>> type R1..Rn.
>>>>>>> The currently rules of auto return deduction is they all have to be
>>>>>>> the same type, and it will be deduced.
>>>>>>> But another reasonable option could have been that the deduced
>>>>>>> return type will be std::common_type<R...>::type.
>>>>>>>
>>>>>>> itaj
>>>>>>>
>>>>>>> On Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:
>>>>>>>
>>>>>>>> Hello everyone,
>>>>>>>> Is there any proposal floating regarding returning an uninitialized
>>>>>>>> optional?
>>>>>>>>
>>>>>>>> I'm referring to the following functions:
>>>>>>>>
>>>>>>>> std::optional<int> get1()
>>>>>>>> {
>>>>>>>> auto opt = make_optional<int>(4);
>>>>>>>> if (opt.has_value()) return opt;
>>>>>>>> return std::nullopt;
>>>>>>>> }
>>>>>>>>
>>>>>>>> auto get2()
>>>>>>>> {
>>>>>>>> auto opt = make_optional<int>(4);
>>>>>>>> if (opt.has_value()) return opt;
>>>>>>>> return std::nullopt;
>>>>>>>> }
>>>>>>>>
>>>>>>>> std::optional<int> get3()
>>>>>>>> {
>>>>>>>> auto opt = make_optional<int>(4);
>>>>>>>> return (opt.has_value() ? opt.value() : std::nullopt;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> The first one compiles, but the second one does not (auto cannot
>>>>>>>> simply deduce the type of nullopt, as it's basically an {} )
>>>>>>>> The third one is also something that I'd expect to be able to do,
>>>>>>>> but the compiler does not allow unary return of such kind.
>>>>>>>>
>>>>>>>> All the best,
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2ee8a6b4-e9b2-4697-a552-da3521dd6d2d%40isocpp.org.
------=_Part_1169_762408317.1542380090047
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>all that said, are there any proposals that=
try to resolve these issues?<br><br>On Friday, 16 November 2018 16:30:05 U=
TC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
dir=3D"ltr">Well, I totally see your point about slicing.<br>And I should =
have add to the requirement of what I called is_stably_convertible, that de=
rived to base is not allowed, and that numeric narrowing are not allowed.<b=
r>Basically everything should allow the Result to be used instead of the So=
urce.<br><br>But ultimately in the case of string to string_view, and the o=
ther cases I mentioned, the underlying problem is that the Result depends o=
n the Source's lifetime.<br><br>Is what you mean about "promotion&=
quot;, that you consider string to string_view an implicit cast but not a p=
romotion?<br>And then you say that the name of is_stably_convertible should=
be is_promotable.<br><br>Either way, the OP has a very reasonable point, a=
nd the right thing to do is explain what would be needed to solve it rather=
than just telling them it's not possible.<div><br></div><div>itaj<br><=
br>On Friday, 16 November 2018 15:12:27 UTC+2, <a>mihailn...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Note that t=
he issue has nothing to do with lifetime.<div>using common_type could also =
lead to slicing</div><div><br></div><div>struct A {};</div><div>struct B : =
A {};</div><div><br></div><div>auto func()</div><div>{</div><div>=C2=A0 =C2=
=A0 if(something)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::common_=
type_t<A, B>(A{});</div><div>=C2=A0 =C2=A0 return=C2=A0 std::common_t=
ype_t<A, B>(B{});</div><div>}=C2=A0<br><br>Ultimately the issue is ab=
out having "type promotion"=C2=A0 -=C2=A0 right now even integer =
promotion does not work - which will require completely new extension point=
s for custom types, incl. optional.</div><div><br></div><div>It is a differ=
ent story if the are really willing to give auto return type such powers.=
=C2=A0</div><div>Auto here is used as a declaration and we want to know wha=
t the declaration is - what the returned type is.</div><div>Right now, when=
we read a function we can "early out" and any return statement w=
ill answer our questions. If we allow proportion, all bets are off=C2=A0</d=
iv><div>-=C2=A0 any return can be a promoting one and we might not even not=
ice it..=C2=A0</div><div><br></div><br>On Friday, November 16, 2018 at 1:44=
:12 PM UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">and constructors like=C2=A0<div>string_view::string_view( st=
d::string const& )</div><div><br></div><div>which are not marked with t=
he 'explicit' keywords, because they are useful in many implicit ca=
ses,</div><div>could be marked with a new keyword 'instable' to set=
stably_convertible to false.<br><br>On Friday, 16 November 2018 13:40:11 U=
TC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Probably more cases could improve safety. The following syntaxes a=
lso allow any implicit conversion, and might benefit from only allowing sta=
bly_convertible ones:<br><br>T x =3D EXPRESSION_WITH_TEMPORARY_<wbr>RESULT;=
<div><br></div><div>T foo() { return EXPRESSION_WITH_TEMPORARY_<wbr>RESULT;=
}</div><div><br></div><div><br></div><div>On Friday, 16 November 2018 13:1=
9:21 UTC+2, Itaj Sherman wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><br>Yeah, true.<br><br>It will require some sort of is_stable=
_valid<T> trait that says a type can be safely returned because it do=
esn't depend on non-owned addresses.<br><div><br></div><div>so value ty=
pes and owner-pointers can be is_stable_valid<T>, while observer poin=
ters, iterators and views cannot.</div><div>wrappers like optional, variant=
, tuple will be is_stable_valid if all their elements are.</div><div><br></=
div><div>if auto function has different return types is can return enable_i=
f_stable_valid_t< commot_type_t<R...> ><br></div><div>template&=
lt; typename T > using enable_if_stable_valid_t =3D enable_if< is_sta=
ble_valid<T>, T >::type;<br></div><div><br></div><div><br></div><d=
iv>an even more generalized notion would be:</div><div><br></div><div><div>=
is_stably_convertible< S, R ></div><div>which will specify that is_co=
nvertible< S, R >, and that the resulting R is no less stable than S.=
</div><div>and define stably_common_type_t< R... > based on is_stably=
_convertible.<br><br>formally:</div></div><div>define the instability-set o=
f and object X as the set of objects whose lifetime X doesn't own, but =
still requires them to be alive for X's contract - depending on the use=
r to make sure they stay alive.</div><div><br></div><div><div>and is_stably=
_convertible< S, R > means that=C2=A0</div><div>1 - the instability s=
et of the resulting R is contained within the instability set of the source=
S</div><div>2 - resulting R doesn't own any objects from the instabili=
ty set of S (that is it doesn't initiate ownership on it).</div></div><=
div><br></div><div>so basically if is_stable_valid<T> then instabilit=
y set is empty.<br></div><div>T* x =3D &a; //instability set is {a}</di=
v><div>T** y =3D &x; //instability set is {x,a}</div><div>std::variant&=
lt;int, T*> z =3D x; //instability set is {a}</div><div><br></div><div>b=
asically:<br></div><div>is_stably_convertible< T, optional<T> >=
=3D=3D true</div><div></div><div>is_stably_convertible< T*, optional<=
;T*> > =3D=3D true</div><div><div>is_stably_convertible< string, s=
tring_view > =3D=3D false<br></div></div><div><div>is_stably_convertible=
< string_view, string > =3D=3D true<br></div></div><div><div>is_stabl=
y_convertible< shared_ptr/unique_ptr, T* > =3D=3D false //both becaus=
e the conversion is not implicit, and even if it were, the instability set =
of the result is bigger.<br></div></div><div>is_stably_convertible< T*, =
shared_ptr/unique_ptr > =3D=3D false //both because the conversion is no=
t implicit, and even if it were, it would take ownership on the unowned.<br=
></div><div><br></div><div>this can also improve safety with the extended l=
ifetime of temporary bounded to reference:<br><br>T& =3D expression; //=
if expression is temporary, will require is_stably_convertible< typeof(e=
xpression), T >, otherwise ill-formed.</div><div><br></div><div>itaj</di=
v><div><br>On Friday, 16 November 2018 10:57:03 UTC+2, <a>mihailn...@gmail.=
com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Naa=
aah<div><br></div><div><div><font face=3D"courier new, monospace">auto func=
()</font></div><div><font face=3D"courier new, monospace">{</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if(something)</font><=
/div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0=
return std::common_type_t<std::<wbr>string_view, std::string>(std::s=
tring_view(<wbr>"sds"));</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"courier n=
ew, monospace">=C2=A0 =C2=A0 return std::common_type_t<std::<wbr>string_=
view, std::string>(std::string("sds"<wbr>));</font></div><div>=
<font face=3D"courier new, monospace">}</font></div></div><div><br>Boom.</d=
iv><div><br><br>On Friday, November 16, 2018 at 2:42:26 AM UTC+2, Itaj Sher=
man wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>I di=
sagree with the other responds. I actually think you have a point.<br><br><=
div>nullopt and optional<int> are not totally "unrelated", =
specifically std::common_type< nullopt, optional<int> >::type =
=3D=3D=3D optional<int>.</div><div><br></div><div>Suppose you have a =
function with several return statements returning type R1..Rn.<br></div><di=
v>The currently rules of auto return deduction is they all have to be the s=
ame type, and it will be deduced.</div><div>But another reasonable option c=
ould have been that the deduced return type will be std::common_type<R..=
..>::type.</div><div><br></div><div>itaj<br></div><div><br></div><div>On =
Monday, 12 November 2018 08:18:59 UTC+2, robert badea wrote:<br></div><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello everyone,=
=C2=A0<div>Is there any proposal floating regarding returning an uninitiali=
zed optional?</div><div><br></div><div>I'm referring to the following f=
unctions:</div><div><br></div><div><div>std::optional<int> get1()</di=
v><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =3D mak=
e_optional<int>(4);</div><div><span style=3D"white-space:pre"> </span=
>if (opt.has_value()) return opt;</div><div><span style=3D"white-space:pre"=
> </span>return std::nullopt;</div><div>}</div><div><br></div><div>auto get=
2()</div><div>{</div><div><span style=3D"white-space:pre"> </span>auto opt =
=3D make_optional<int>(4);</div><div><span style=3D"white-space:pre">=
</span>if (opt.has_value()) return opt;</div><div><span style=3D"white-spa=
ce:pre"> </span>return std::nullopt;</div><div>}</div><div><br></div><div>s=
td::optional<int> get3()</div><div>{</div><div><span style=3D"white-s=
pace:pre"> </span>auto opt =3D make_optional<int>(4);</div><div><span=
style=3D"white-space:pre"> </span>return (opt.has_value() ? opt.value() : =
std::nullopt;</div><div>}</div><div><br></div></div><div><br></div><div>The=
first one compiles, but the second one does not (auto cannot simply deduce=
the type of nullopt, as it's basically an {} )</div><div>The third one=
is also something that I'd expect to be able to do, but the compiler d=
oes not allow unary return of such kind.</div><div><br></div><div>All the b=
est,</div><div>Robert</div><div><br></div></div></blockquote></div></div></=
blockquote></div></div></blockquote></div></div></blockquote></div></div></=
blockquote></div></div></blockquote></div></blockquote></div></div></blockq=
uote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2ee8a6b4-e9b2-4697-a552-da3521dd6d2d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ee8a6b4-e9b2-4697-a552-da3521dd6d2d=
%40isocpp.org</a>.<br />
------=_Part_1169_762408317.1542380090047--
------=_Part_1168_283770705.1542380090046--
.