--001a11336bbad3de8504e4ecef43
Content-Type: text/plain; charset=ISO-8859-1

I'm actually surprised that the conversion is *not* considered explicit in
both:
    [1] bool test() { return some_optional; }
and
    [2] bool foobar = some_optional;

In both cases it's very clear a conversion to bool is desired. 'bool' is
even explicitly written, unlike in
    [3] if (some_optional);
in which it is considered 'explicit', even though to me it seems at most as
explicit than the first two examples I gave.

I thought explicit operator bool was only to prevent
    [4] int baz = some_optional;
but I don't see why it would be handy prevent [1] and [2], which seems
pretty explicit.

The good old 'safe bool idiom' does allow [1], [2] and [3], but not [4],
which is usually (always?) what I want. (In contrast to the explicit
operator bool, which only allows [3].)



2013/8/27 Xeo <hivemaster@hotmail.de>

> Conversions to bool are generally a good thing: they're like a uniform
> interface for checking the "validity" of an object, if the "validity" is
> unambiguous - like for pointers. However, as could be see with the
> invention of the "safe-bool idiom", *implicit* conversions to bool can
> cause many problems and aren't very favorable. C++11 added explicit
> conversion operators and so-called *contextual conversions to bool*, which
> is a definite improvement - but the built-in types still suffer from
> implicit conversions.
>
> On a slight tangent: Something that has formed in the back of my head in
> the last few days was an unary postfix `operator?`, which explicitly asks
> for a contextual conversion to bool. It's basically the conditional
> operator without the branches.
> The idea originally came up when somebody wanted to provide a function
> which checks the validity of his object by inspecting the underlying
> `std::optional`-like object which provides an `explicit operator bool`, but
> not an `engaged()` or `initialized()` or similar function.
> That could be seen as an interface-fail, but one has to live with it.
>
> class foo{
>   std::optional<T> _impl;
> // ...
>   bool test() const{ return _impl; }
> };
>
> This obviously won't compile, as the conversion to bool would be
> considered *implicit* here. We then discussed several "workarounds":
>
> return bool(_impl); // very subjective feeling: meeeeeeeh
> return static_cast<bool>(_impl); // unwieldy
> return _impl ? true : false; // feels redundant
> return _impl && true; // feels redundant and obscure
> return !!_impl; // double-banging in C++? oh come on
>
> In comes `operator?`
>
> return _impl?; // concise and (imo) clear
>
> So, returning from that tangent, said `operator?` would then also be used
> with the fundamental types, providing a clear migration path for code that
> relies on the implicit conversion to bool.
>
> There's no proposal at this point, as I just want to collect general
> interest and feedback.
>
> Regards
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>I&#39;m actually surprised that the conversion is *no=
t* considered explicit in both:<br>=A0=A0=A0 [1] bool test() { return some_=
optional; }<br>and<br>=A0=A0=A0 [2] bool foobar =3D some_optional;<br><br>I=
n both cases it&#39;s very clear a conversion to bool is desired. &#39;bool=
&#39; is even explicitly written, unlike in<br>

=A0=A0=A0 [3] if (some_optional);<br>in which it is considered &#39;explici=
t&#39;, even though to me it seems at most as explicit than the first two e=
xamples I gave.<br><br>I thought explicit operator bool was only to prevent=
<br>

=A0=A0=A0 [4] int baz =3D some_optional;<br>but I don&#39;t see why it woul=
d be handy prevent [1] and [2], which seems pretty explicit.<br></div><br>T=
he good old &#39;safe bool idiom&#39; does allow [1], [2] and [3], but not =
[4], which is usually (always?) what I want. (In contrast to the explicit o=
perator bool, which only allows [3].)<br>

<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/8/27 Xeo <span dir=3D"ltr">&lt;<a href=3D"mailto:hivemaster@ho=
tmail.de" target=3D"_blank">hivemaster@hotmail.de</a>&gt;</span><br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">

<div dir=3D"ltr">Conversions to bool are generally a good thing: they&#39;r=
e like a uniform interface for checking the &quot;validity&quot; of an obje=
ct, if the &quot;validity&quot; is unambiguous - like for pointers. However=
, as could be see with the invention of the &quot;safe-bool idiom&quot;, *i=
mplicit* conversions to bool can cause many problems and aren&#39;t very fa=
vorable. C++11 added explicit conversion operators and so-called *contextua=
l conversions to bool*, which is a definite improvement - but the built-in =
types still suffer from implicit conversions.<br>

<br>On a slight tangent: Something that has formed in the back of my head i=
n the last few days was an unary postfix `operator?`, which explicitly asks=
 for a contextual conversion to bool. It&#39;s basically the conditional op=
erator without the branches.<br>

The idea originally came up when somebody wanted to provide a function whic=
h checks the validity of his object by inspecting the underlying `std::opti=
onal`-like object which provides an `explicit operator bool`, but not an `e=
ngaged()` or `initialized()` or similar function.<br>

That could be seen as an interface-fail, but one has to live with it.<br><b=
r><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div>

<span style=3D"color:#008">class</span><span style> foo</span><span style=
=3D"color:#660">{</span><span style><br>=A0 std</span><span style=3D"color:=
#660">::</span><span style>optional</span><span style=3D"color:#660">&lt;</=
span><span style>T</span><span style=3D"color:#660">&gt;</span><span style>=
 _impl</span><span style=3D"color:#660">;</span><span style><br>

</span><span style=3D"color:#800">// ...</span><span style><br>=A0 </span><=
span style=3D"color:#008">bool</span><span style> test</span><span style=3D=
"color:#660">()</span><span style> </span><span style=3D"color:#008">const<=
/span><span style=3D"color:#660">{</span><span style> </span><span style=3D=
"color:#008">return</span><span style> _impl</span><span style=3D"color:#66=
0">;</span><span style> </span><span style=3D"color:#660">}</span><span sty=
le><br>

</span><span style=3D"color:#660">};</span><span style><br></span></div></c=
ode></div><br>This obviously won&#39;t compile, as the conversion to bool w=
ould be considered *implicit* here. We then discussed several &quot;workaro=
unds&quot;:<br>

<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#008">return</span><span style> </span><span style=3D=
"color:#008">bool</span><span style=3D"color:#660">(</span><span style>_imp=
l</span><span style=3D"color:#660">);</span><span style> </span><span style=
=3D"color:#800">// very subjective feeling: meeeeeeeh</span><span style><br=
>

</span><span style=3D"color:#008">return</span><span style> </span><span st=
yle=3D"color:#008">static_cast</span><span style=3D"color:#080">&lt;bool&gt=
;</span><span style=3D"color:#660">(</span><span style>_impl</span><span st=
yle=3D"color:#660">);</span><span style> </span><span style=3D"color:#800">=
// unwieldy</span><span style><br>

</span><span style=3D"color:#008">return</span><span style> _impl </span><s=
pan style=3D"color:#660">?</span><span style> </span><span style=3D"color:#=
008">true</span><span style> </span><span style=3D"color:#660">:</span><spa=
n style> </span><span style=3D"color:#008">false</span><span style=3D"color=
:#660">;</span><span style> </span><span style=3D"color:#800">// feels redu=
ndant</span><span style><br>

</span><span style=3D"color:#008">return</span><span style> _impl </span><s=
pan style=3D"color:#660">&amp;&amp;</span><span style> </span><span style=
=3D"color:#008">true</span><span style=3D"color:#660">;</span><span style> =
</span><span style=3D"color:#800">// feels redundant and obscure</span><spa=
n style><br>

</span><span style=3D"color:#008">return</span><span style> </span><span st=
yle=3D"color:#660">!!</span><span style>_impl</span><span style=3D"color:#6=
60">;</span><span style> </span><span style=3D"color:#800">// double-bangin=
g in C++? oh come on</span></div>

</code></div><br>In comes `operator?`<br><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">return=
</span><span style> _impl</span><span style=3D"color:#660">?;</span><span s=
tyle> </span><span style=3D"color:#800">// concise and (imo) clear</span><s=
pan style><br>

</span></div></code></div><br>So, returning from that tangent, said `operat=
or?` would then also be used with the fundamental types, providing a clear =
migration path for code that relies on the implicit conversion to bool.<br>

<br>There&#39;s no proposal at this point, as I just want to collect genera=
l interest and feedback.<br><br>Regards<span class=3D"HOEnZb"><font color=
=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"><font color=3D"=
#888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11336bbad3de8504e4ecef43--

.

------=_Part_1451_4713884.1377608122294
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, August 27, 2013 1:22:53 PM UTC+1, Maurice Bos wrote:
>
> I'm actually surprised that the conversion is *not* considered explicit in
> both:
>     [1] bool test() { return some_optional; }
> and
>     [2] bool foobar = some_optional;
>

Are you also surprised that a type with an explicit constructor can't be
used in the same way?

std::unique_ptr<int> ptr() { return new int; }

std::unique_ptr<int> ptr = new int;

Personally I'd like [1] to be considered "explicit" for both constructors
and conversions operators, but until then it's better that the rules are
consistent.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1451_4713884.1377608122294
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 1:22:53 PM UTC+1, Maur=
ice Bos 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"=
><div>I'm actually surprised that the conversion is *not* considered explic=
it in both:<br>&nbsp;&nbsp;&nbsp; [1] bool test() { return some_optional; }=
<br>and<br>&nbsp;&nbsp;&nbsp; [2] bool foobar =3D some_optional;<br></div><=
/div></blockquote><div><br>Are you also surprised that a type with an expli=
cit constructor can't be used in the same way?<br><br>std::unique_ptr&lt;in=
t&gt; ptr() { return new int; }<br><br>std::unique_ptr&lt;int&gt; ptr =3D n=
ew int;<br><br>Personally I'd like [1] to be considered "explicit" for both=
 constructors and conversions operators, but until then it's better that th=
e rules are consistent.<br></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1451_4713884.1377608122294--

.

------=_Part_475_29402365.1377610812322
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, August 27, 2013 8:05:32 PM UTC+8, Xeo wrote:
>
> Conversions to bool are generally a good thing: they're like a uniform
> interface for checking the "validity" of an object, if the "validity" is
> unambiguous - like for pointers. However, as could be see with the
> invention of the "safe-bool idiom", *implicit* conversions to bool can
> cause many problems and aren't very favorable. C++11 added explicit
> conversion operators and so-called *contextual conversions to bool*, which
> is a definite improvement - but the built-in types still suffer from
> implicit conversions.
>
> On a slight tangent: Something that has formed in the back of my head in
> the last few days was an unary postfix `operator?`, which explicitly asks
> for a contextual conversion to bool. It's basically the conditional
> operator without the branches.
>

Unary postfix "?" used as the condition to ternary "?" would invite the
"??" sequence which introduces a trigraph. That's just a unary "!" away
from disaster.

There's no proposal at this point, as I just want to collect general
> interest and feedback.
>

It sounds like you proposed a postfix "?" operator. The benefits seem very
dubious.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_475_29402365.1377610812322
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 27, 2013 8:05:32 PM UTC+8, Xeo =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Convers=
ions to bool are generally a good thing: they're like a uniform interface f=
or checking the "validity" of an object, if the "validity" is unambiguous -=
 like for pointers. However, as could be see with the invention of the "saf=
e-bool idiom", *implicit* conversions to bool can cause many problems and a=
ren't very favorable. C++11 added explicit conversion operators and so-call=
ed *contextual conversions to bool*, which is a definite improvement - but =
the built-in types still suffer from implicit conversions.<br><br>On a slig=
ht tangent: Something that has formed in the back of my head in the last fe=
w days was an unary postfix `operator?`, which explicitly asks for a contex=
tual conversion to bool. It's basically the conditional operator without th=
e branches.<br></div></blockquote><div>&nbsp;</div><div dir=3D"ltr">Unary p=
ostfix "?" used as the condition to ternary "?" would invite the "??" seque=
nce which introduces a trigraph. That's just a unary "!" away from disaster=
..<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">There's =
no proposal at this point, as I just want to collect general interest and f=
eedback.<br></blockquote><br>It sounds like you proposed a postfix "?" oper=
ator. The benefits seem very dubious.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_475_29402365.1377610812322--

.

------=_Part_95_12514320.1377611500431
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, August 27, 2013 3:40:12 PM UTC+2, David Krauss wrote
>
>
> Unary postfix "?" used as the condition to ternary "?" would invite the
> "??" sequence which introduces a trigraph. That's just a unary "!" away
> from disaster.
>

Although I see the problem, since the conditional operator already invokes
a contextual conversion to bool, you don't need postfix-? here. Also, even
in the event that you end up with a trigraphed `|`, it will yield a
hard-error, albeit not a very intuitive one I admit.


>
> There's no proposal at this point, as I just want to collect general
>> interest and feedback.
>>
>
> It sounds like you proposed a postfix "?" operator. The benefits seem very
> dubious.
>

The proposal is actually a combination of what is in the topic of the
thread and the postfix-`operator?`, since just the former would provide no
clear migration path.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_95_12514320.1377611500431
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 27, 2013 3:40:12 PM UTC+2, David Krauss=
 wrote<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&n=
bsp;</div><div dir=3D"ltr">Unary postfix "?" used as the condition to terna=
ry "?" would invite the "??" sequence which introduces a trigraph. That's j=
ust a unary "!" away from disaster.<br></div></div></blockquote><div><br>Al=
though I see the problem, since the conditional operator already invokes a =
contextual conversion to bool, you don't need postfix-? here. Also, even in=
 the event that you end up with a trigraphed `|`, it will yield a hard-erro=
r, albeit not a very intuitive one I admit.<br>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div dir=3D"ltr"><br><blockqu=
ote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex" class=3D"gmail_quote">There's no proposal at this point=
, as I just want to collect general interest and feedback.<br></blockquote>=
<br>It sounds like you proposed a postfix "?" operator. The benefits seem v=
ery dubious.<br></div></div></blockquote><div><br>The proposal is actually =
a combination of what is in the topic of the thread and the postfix-`operat=
or?`, since just the former would provide no clear migration path. <br></di=
v></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_95_12514320.1377611500431--

.