Hi,

Is there any way to "fix" std::function's function call operator to not
throw on empty, but make it UB? It expands to quite some more code than
should be necessary to call a std::function, even if your own code's
precondition is that the object is not empty. This is in violation of
DPFWYDN (don't pay for what you don't use), because there's no way to
call the function without the check.

Consider, otoh, std::vector::operator[] vs. std::vector::at(). The first
called with an index out of range is UB while the second has defined
behaviour: an exception is thrown. Here, the user can choose whether to
pay the price for checking or not. With std::function, there's no way to
forego the check - at least portably. GCC can be persuaded to drop all
checks when the function call is preceded by if (!f)
__builtin_unreachable(). Clang ignores this:

--
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/6e84f31f1801bcc16a054279eede5e02%40kdab.com.

.

On 2018-04-18 10:33, Mutz, Marc wrote:
> Hi,
>
> Is there any way to "fix" std::function's function call operator to
> not throw on empty, but make it UB? It expands to quite some more code
> than should be necessary to call a std::function, even if your own
> code's precondition is that the object is not empty. This is in
> violation of DPFWYDN (don't pay for what you don't use), because
> there's no way to call the function without the check.
>
> Consider, otoh, std::vector::operator[] vs. std::vector::at(). The
> first called with an index out of range is UB while the second has
> defined behaviour: an exception is thrown. Here, the user can choose
> whether to pay the price for checking or not. With std::function,
> there's no way to forego the check - at least portably. GCC can be
> persuaded to drop all checks when the function call is preceded by if
> (!f) __builtin_unreachable(). Clang ignores this:

Link was missing:

https://godbolt.org/g/JniNxM

--
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/6e7ddc6531aca86bab3fcbc351203b01%40kdab.com.

.

--001a11449a9e2ca212056a252d2f
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 18, 2018 at 3:33 AM, Mutz, Marc <marc@kdab.com> wrote:

> Is there any way to "fix" std::function's function call operator to not
> throw on empty, but make it UB?


That is a breaking change, so the bar to change it is very high.  The onus
is on the proposer to explore how much and what kind of real code is
dependent on the current behavior.

At best, it could be deprecated in C++20 and removed in C++23.

[Please do not count this message as an endorsement]
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BMSZs2pAi2eR8AE_u5JEKCVJiNxbzCFvt42OF9qAT2Upg%40mail.gmail.com.

--001a11449a9e2ca212056a252d2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 18, 2018 at 3:33 AM, Mutz, Marc <span dir=3D"l=
tr">&lt;<a href=3D"mailto:marc@kdab.com" target=3D"_blank">marc@kdab.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">Is there any way to &quot;fix&quot; std::f=
unction&#39;s function call operator to not throw on empty, but make it UB?=
</blockquote><div><br></div><div>That is a breaking change, so the bar to c=
hange it is very high.=C2=A0 The onus is on the proposer to explore how muc=
h and what kind of real code is dependent on the current behavior.</div><di=
v><br></div><div>At best, it could be deprecated in C++20 and removed in C+=
+23.</div><div><br></div><div>[Please do not count this message as an endor=
sement]</div>--=C2=A0<br></div><div class=3D"m_7771028301179621538gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=
=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D=
"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a=
><wbr>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

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

--001a11449a9e2ca212056a252d2f--

.

--0000000000009e23b9056a256fd9
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 18, 2018 at 4:33 AM Mutz, Marc <marc@kdab.com> wrote:

> Hi,
>
> Is there any way to "fix" std::function's function call operator to not
> throw on empty, but make it UB? It expands to quite some more code than
> should be necessary to call a std::function, even if your own code's
> precondition is that the object is not empty.
>

I personally do agree that this should just be a precondition violation.
The standard library makes this kind of "mistake" in quite a few places
(and we continue to make similar decisions with respect to new facilities).
That said, there is a reason that this keeps happening and why I have
"mistake" in quotes -- it is difficult to get consensus for the alternative
and so it is not nearly universally considered a mistake. My gut is that
this is even more true with respect to the community as a whole, separate
from the small subset that makes up those who participate in the committee.
As well, as Nevin mentioned, once we have the behavior defined, it is
difficult to migrate away because people may be depending on that defined
behavior (whereas widening a contract is "safe" even though it, too, is
controversial for other reasons). Because of this, we end up having wider
contracts than many may consider ideal.

I think that if we are to see an overall change in how we deal with
contracts, we'd need a more general paper that very accurately expresses
*where* and *why* we should favor narrow contracts (and, somewhat related,
why "logic errors" are not a good match for exceptions). We'd then need to
get consensus on that and push it as a guideline LEWG sticks to. If you
think that this is at all feasible, then it may be worth pursuing, but it
would be difficult.

[You can count this message as an endorsement from me as an individual,
though I am not optimistic]

-- Matt Calabrese

--
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/CANh8DEmHXkBXrvx%3DbPeuA1qu1_nJE2TH%2BWhvwYmQJUqzxk-Xew%40mail.gmail.com.

--0000000000009e23b9056a256fd9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Apr 18, 2018 at 4:33 AM Mutz, Marc &lt;<a href=3D"mailto:marc@kdab.com">m=
arc@kdab.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Is there any way to &quot;fix&quot; std::function&#39;s function call opera=
tor to not <br>
throw on empty, but make it UB? It expands to quite some more code than <br=
>
should be necessary to call a std::function, even if your own code&#39;s <b=
r>
precondition is that the object is not empty.<br></blockquote><div><br></di=
v><div>I personally do agree that this should just be a precondition violat=
ion. The standard library makes this kind of &quot;mistake&quot; in quite a=
 few places (and we continue to make similar decisions with respect to new =
facilities). That said, there is a reason that this keeps happening and why=
 I have &quot;mistake&quot; in quotes -- it is difficult to get consensus f=
or the alternative and so it is not nearly universally considered a mistake=
.. My gut is that this is even more true with respect to the community as a =
whole, separate from the small subset that makes up those who participate i=
n the committee. As well, as Nevin mentioned, once we have the behavior def=
ined, it is difficult to migrate away because people may be depending on th=
at defined behavior (whereas widening a contract is &quot;safe&quot; even t=
hough it, too, is controversial for other reasons). Because of this, we end=
 up having wider contracts than many may consider ideal.</div><div><br></di=
v><div>I think that if we are to see an overall change in how we deal with =
contracts, we&#39;d need a more general paper that very accurately expresse=
s <i>where</i> and <i>why</i>=C2=A0we should favor narrow contracts (and, s=
omewhat related, why &quot;logic errors&quot; are not a good match for exce=
ptions). We&#39;d then need to get consensus on that and push it as a guide=
line LEWG sticks to. If you think that this is at all feasible, then it may=
 be worth pursuing, but it would be difficult.</div><div><br></div><div>[Yo=
u can count this message as an endorsement from me as an individual, though=
 I am not optimistic]</div><div><br></div><div>-- Matt Calabrese</div></div=
></div>

<p></p>

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

--0000000000009e23b9056a256fd9--

.

The best solution would in my opinion be to have that facility as a
customisation point in a new std::basic_function template. Personally,
I would prefer std::function to abort if called in an empty state.
I believe that we already have enough  undefined behaviour in C++.

/Peter

On Wed, Apr 18, 2018 at 10:33 AM, Mutz, Marc <marc@kdab.com> wrote:
> Hi,
>
> Is there any way to "fix" std::function's function call operator to not
> throw on empty, but make it UB? It expands to quite some more code than
> should be necessary to call a std::function, even if your own code's
> precondition is that the object is not empty. This is in violation of
> DPFWYDN (don't pay for what you don't use), because there's no way to call
> the function without the check.
>
> Consider, otoh, std::vector::operator[] vs. std::vector::at(). The first
> called with an index out of range is UB while the second has defined
> behaviour: an exception is thrown. Here, the user can choose whether to pay
> the price for checking or not. With std::function, there's no way to forego
> the check - at least portably. GCC can be persuaded to drop all checks when
> the function call is preceded by if (!f) __builtin_unreachable(). Clang
> ignores this:
>
> --
> 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/6e84f31f1801bcc16a054279eede5e02%40kdab.com.

--
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/CANPtknyHJ91DUb4wHPGMdcSkizZcciJhqDbcqFeYdw12s%2BZvLw%40mail.gmail.com.

.

--94eb2c1925c08b983c056a263f3d
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 18, 2018 at 3:59 PM, Peter Koch Larsen <
peter.koch.larsen@gmail.com> wrote:

> The best solution would in my opinion be to have that facility as a
> customisation point in a new std::basic_function template. Personally,
> I would prefer std::function to abort if called in an empty state.
> I believe that we already have enough  undefined behaviour in C++.
>

-100.

IMO, basing things on global state (either compile-time via a trait/macro
somewhere or run-time) is generally a bad idea, as it makes it hard to
interop with other libraries which expect different state.  If you have
different behaviors, they should be either differently named functions
and/or different types.

You could encode this state as a template parameter, but then we end up
with the same problem that we have with containers having allocators as
template parameters in that they aren't interoperable, and we end up
inventing various views and spans to deal with that issue.  At least that
division is between owning and non-owning.

I agree with Matt in that it probably should have been ub to start with
(but if it was between exceptions or not having std::function in C++, I
would have voted for exceptions), but that ship sailed long ago.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BPENMXi%2BZNVxHPSVCNB2%2BKCNZJknUkwiEwvxFBrdCz11Q%40mail.gmail.com.

--94eb2c1925c08b983c056a263f3d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 18, 2018 at 3:59 PM, Peter Koch Larsen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:peter.koch.larsen@gmail.com" target=3D"_bl=
ank">peter.koch.larsen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The bes=
t solution would in my opinion be to have that facility as a<br>
customisation point in a new std::basic_function template. Personally,<br>
I would prefer std::function to abort if called in an empty state.<br>
I believe that we already have enough=C2=A0 undefined behaviour in C++.<br>=
</blockquote><div><br></div><div>-100.</div><div><br></div><div>IMO, basing=
 things on global state (either compile-time via a trait/macro somewhere or=
 run-time) is generally a bad idea, as it makes it hard to interop with oth=
er libraries which expect different state.=C2=A0 If you have different beha=
viors, they should be either differently named functions and/or different t=
ypes.</div><div><br></div><div>You could encode this state as a template pa=
rameter, but then we end up with the same problem that we have with contain=
ers having allocators as template parameters in that they aren&#39;t intero=
perable, and we end up inventing various views and spans to deal with that =
issue.=C2=A0 At least that division is between owning and non-owning.</div>=
<div><br></div><div>I agree with Matt in that it probably should have been =
ub to start with (but if it was between exceptions or not having std::funct=
ion in C++, I would have voted for exceptions), but that ship sailed long a=
go.</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmai=
l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div=
></div></div></div></div>
</div></div>

<p></p>

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

--94eb2c1925c08b983c056a263f3d--

.

--0000000000007f65f0056a275488
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 18, 2018, 17:00 Peter Koch Larsen <peter.koch.larsen@gmail.com>
wrote:

> The best solution would in my opinion be to have that facility as a
> customisation point in a new std::basic_function template. Personally,
> I would prefer std::function to abort if called in an empty state.
> I believe that we already have enough  undefined behaviour in C++.
>

I find this kind of view troubling. A complaint implementation can already
provide this behavior and document it. As well, if and when we get a
contracts language feature, you will also likely get the control that you
want and force any checked preconditions into an abort. I think widening
contracts and specifying an abort as a requirement would be a huge mistake
and not at all in the best interests of C++. I also find it even less
likely than us moving in the opposite direction.

Anyway, I suspect that the discussion is likely best to be focused on what
should or should not be a precondition, rather than anything directly about
UB. Contracts as a language feature will likely make it much more clear
that this is all that really matters.


>

--
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/CANh8DEkk%2BwYc4kG4TAfMx9eNboU0tDp6cnYu%3DhFPn_oa%2Bs%3DiHg%40mail.gmail.com.

--0000000000007f65f0056a275488
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Wed, Apr 18, 2018, 17:00 Peter Koch Larsen &lt;<a href=3D"mailto:peter.k=
och.larsen@gmail.com">peter.koch.larsen@gmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">The best solution would in my opinion be to h=
ave that facility as a<br>
customisation point in a new std::basic_function template. Personally,<br>
I would prefer std::function to abort if called in an empty state.<br>
I believe that we already have enough=C2=A0 undefined behaviour in C++.<br>=
</blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I fi=
nd this kind of view troubling. A complaint implementation can already prov=
ide this behavior and document it. As well, if and when we get a contracts =
language feature, you will also likely get the control that you want and fo=
rce any checked preconditions into an abort. I think widening contracts and=
 specifying an abort as a requirement would be a huge mistake and not at al=
l in the best interests of C++. I also find it even less likely than us mov=
ing in the opposite direction.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Anyway, I suspect that the discussion is likely best to be focused o=
n what should or should not be a precondition, rather than anything directl=
y about UB. Contracts as a language feature will likely make it much more c=
lear that this is all that really matters.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><br>
</blockquote></div></div></div>

<p></p>

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

--0000000000007f65f0056a275488--

.

------=_Part_775_602634850.1524106175891
Content-Type: multipart/alternative;
 boundary="----=_Part_776_475638464.1524106175891"

------=_Part_776_475638464.1524106175891
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Wednesday, April 18, 2018 at 1:33:49 AM UTC-7, Mutz, Marc wrote:
>
> Hi,=20
>
> Is there any way to "fix" std::function's function call operator to not=
=20
> throw on empty, but make it UB? It expands to quite some more code than=
=20
> should be necessary to call a std::function, even if your own code's=20
> precondition is that the object is not empty. This is in violation of=20
> DPFWYDN (don't pay for what you don't use), because there's no way to=20
> call the function without the check.=20
>
> Consider, otoh, std::vector::operator[] vs. std::vector::at(). The first=
=20
> called with an index out of range is UB while the second has defined=20
> behaviour: an exception is thrown. Here, the user can choose whether to=
=20
> pay the price for checking or not. With std::function, there's no way to=
=20
> forego the check - at least portably. GCC can be persuaded to drop all=20
> checks when the function call is preceded by if (!f)=20
> __builtin_unreachable(). Clang ignores this:=20
>

https://godbolt.org/g/JniNxM=20
<https://www.google.com/url?q=3Dhttps%3A%2F%2Fgodbolt.org%2Fg%2FJniNxM&sa=
=3DD&sntz=3D1&usg=3DAFQjCNHy4AeRtqbo0BqHCYJRithfY07qjw>
 =20

Ehh, IMO that's just a (relatively) crappy library implementation. The best=
=20
way to implement this "default" throwing behavior (just like the best way=
=20
to implement the "default" throwing behavior for the single-variant=20
std::visit) is to write a function that throws the exception, and make sure=
=20
that std::function's "default" constructor initializes the object with a=20
pointer to that function.
https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h#L88
Maybe a patch would be accepted by libstdc++?

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9f1adf57-cfed-4551-8f70-afe6619c499a%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Wednesday, April 18, 2018 at 1:33:49 AM UTC-7, =
Mutz, Marc wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>Is there any way to &quot;fix&quot; std::function&#39;s function call o=
perator to not=20
<br>throw on empty, but make it UB? It expands to quite some more code than=
=20
<br>should be necessary to call a std::function, even if your own code&#39;=
s=20
<br>precondition is that the object is not empty. This is in violation of=
=20
<br>DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39;s=
 no way to=20
<br>call the function without the check.
<br>
<br>Consider, otoh, std::vector::operator[] vs. std::vector::at(). The firs=
t=20
<br>called with an index out of range is UB while the second has defined=20
<br>behaviour: an exception is thrown. Here, the user can choose whether to=
=20
<br>pay the price for checking or not. With std::function, there&#39;s no w=
ay to=20
<br>forego the check - at least portably. GCC can be persuaded to drop all=
=20
<br>checks when the function call is preceded by if (!f)=20
<br>__builtin_unreachable(). Clang ignores this:
<br></blockquote><div><br></div><div><a href=3D"https://www.google.com/url?=
q=3Dhttps%3A%2F%2Fgodbolt.org%2Fg%2FJniNxM&amp;sa=3DD&amp;sntz=3D1&amp;usg=
=3DAFQjCNHy4AeRtqbo0BqHCYJRithfY07qjw" target=3D"_blank" rel=3D"nofollow" s=
tyle=3D"cursor: pointer;">https://godbolt.org/g/JniNxM</a>=C2=A0=C2=A0</div=
><div><br></div><div>Ehh, IMO that&#39;s just a (relatively) crappy library=
 implementation. The best way to implement this &quot;default&quot; throwin=
g behavior (just like the best way to implement the &quot;default&quot; thr=
owing behavior for the single-variant std::visit) is to write a function th=
at throws the exception, and make sure that std::function&#39;s &quot;defau=
lt&quot; constructor initializes the object with a pointer to that function=
..</div><div><a href=3D"https://github.com/WG21-SG14/SG14/blob/master/SG14/i=
nplace_function.h#L88">https://github.com/WG21-SG14/SG14/blob/master/SG14/i=
nplace_function.h#L88</a><br></div><div>Maybe a patch would be accepted by =
libstdc++?</div><div><br></div><div>=E2=80=93Arthur</div></div>

<p></p>

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

------=_Part_776_475638464.1524106175891--

------=_Part_775_602634850.1524106175891--

.

On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:
> Is there any way to "fix" std::function's function call operator to not
> throw on empty, but make it UB? It expands to quite some more code than
> should be necessary to call a std::function, even if your own code's
> precondition is that the object is not empty. This is in violation of
> DPFWYDN (don't pay for what you don't use), because there's no way to
> call the function without the check.

Maybe this can be done exactly like std::vector's at() and operator[]: add a
new member, like call(...) or invoke(...).

Then the operator()(Args... args) becomes:

 if (!*this)
  throw something();
 return call(args...);

--
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/1998884.W0C68xiBVJ%40tjmaciei-mobl1.

.

On 2018-04-19 04:49, Arthur O'Dwyer wrote:
> On Wednesday, April 18, 2018 at 1:33:49 AM UTC-7, Mutz, Marc wrote:
>
>> Hi,
>>
>> Is there any way to "fix" std::function's function call operator to
>> not
>> throw on empty, but make it UB? It expands to quite some more code
>> than
>> should be necessary to call a std::function, even if your own code's
>>
>> precondition is that the object is not empty. This is in violation
>> of
>> DPFWYDN (don't pay for what you don't use), because there's no way
>> to
>> call the function without the check.
>>
>> Consider, otoh, std::vector::operator[] vs. std::vector::at(). The
>> first
>> called with an index out of range is UB while the second has defined
>>
>> behaviour: an exception is thrown. Here, the user can choose whether
>> to
>> pay the price for checking or not. With std::function, there's no
>> way to
>> forego the check - at least portably. GCC can be persuaded to drop
>> all
>> checks when the function call is preceded by if (!f)
>> __builtin_unreachable(). Clang ignores this:
>
> https://godbolt.org/g/JniNxM [1]
>
> Ehh, IMO that's just a (relatively) crappy library implementation. The
> best way to implement this "default" throwing behavior (just like the
> best way to implement the "default" throwing behavior for the
> single-variant std::visit) is to write a function that throws the
> exception, and make sure that std::function's "default" constructor
> initializes the object with a pointer to that function.
> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h#L88

Indeed, that would fix the problem, too. But it has two problems:

1. How to implement function::operator bool(), then? You can't compare
function pointers, or vtable addresses: You need to define the
function/variable inline, because you don't know a-priori which template
args you're going to be instantiated with. Inline functions and
(probably) variables may be duplicated between executables
(SO/DLL/EXE/...), leading to the usual problems (here: an empty
function<> created in client code does not appear empty in out-of-line
library code). The inplace_function implementation seems to have this
problem, btw.

2. People expect that storing nullptr in a function<> makes it empty,
and, likewise, that an empty function<> stores nullptr. This is testable
with function::target(). So you would have to check for and convert
from/to nullptr at assign and target time. I don't think target() is
particularly critical here, but having an additional check in the ctor
is probably going to code someone dearly, somewhere, as would the lea
instead of the nullptr mov.

> Maybe a patch would be accepted by libstdc++?

Given the two caveats above, I'm not sure it would.

I guess (1) could be solved with a tagged pointer, but by using bit
twiddling, (2) could become even worse.

Thanks,
Marc

--
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/cc56989ca74013afd5c2b6fc6734320c%40kdab.com.

.

On 2018-04-19 11:28, Mutz, Marc wrote:
> is probably going to code someone dearly, somewhere

s/code/cost/

--
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/20435b993c9c221cd82d46e00d2f23c5%40kdab.com.

.

--00000000000018f6a2056a4876c8
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 19, 2018 at 4:04 AM Thiago Macieira <thiago@macieira.org> wrote:

> On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:
> > Is there any way to "fix" std::function's function call operator to not
> > throw on empty, but make it UB? It expands to quite some more code than
> > should be necessary to call a std::function, even if your own code's
> > precondition is that the object is not empty. This is in violation of
> > DPFWYDN (don't pay for what you don't use), because there's no way to
> > call the function without the check.
>
> Maybe this can be done exactly like std::vector's at() and operator[]: add
> a
> new member, like call(...) or invoke(...).
>
> Then the operator()(Args... args) becomes:
>
>         if (!*this)
>                 throw something();
>         return call(args...);
>

I know that we do this in a couple of places in the standard library, but I
consider it a mistake and a symptom of us just not coming to consensus on
what makes for a good contract. It'd be disappointing if every time we were
to encounter a situation like this we'd have two versions of the same
function. Thankfully we don't do it *too* much right now, but the places
that we do aren't particularly special and it's an unfortunate precedent.

--
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/CANh8DE%3DUtRf9APhFLVt_TEU-mYPcsMqNk8gS3xGXX2Tp-Y_uQg%40mail.gmail.com.

--00000000000018f6a2056a4876c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Apr 19=
, 2018 at 4:04 AM Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.org=
">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:<br>
&gt; Is there any way to &quot;fix&quot; std::function&#39;s function call =
operator to not<br>
&gt; throw on empty, but make it UB? It expands to quite some more code tha=
n<br>
&gt; should be necessary to call a std::function, even if your own code&#39=
;s<br>
&gt; precondition is that the object is not empty. This is in violation of<=
br>
&gt; DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39;=
s no way to<br>
&gt; call the function without the check.<br>
<br>
Maybe this can be done exactly like std::vector&#39;s at() and operator[]: =
add a <br>
new member, like call(...) or invoke(...).<br>
<br>
Then the operator()(Args... args) becomes:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!*this)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw something();<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return call(args...);<br></blockquote><div><br>=
</div><div>I know that we do this in a couple of places in the standard lib=
rary, but I consider it a mistake and a symptom of us just not coming to co=
nsensus on what makes for a good contract. It&#39;d be disappointing if eve=
ry time we were to encounter a situation like this we&#39;d have two versio=
ns of the same function. Thankfully we don&#39;t do it *too* much right now=
, but the places that we do aren&#39;t particularly special and it&#39;s an=
 unfortunate precedent.<br></div></div></div>

<p></p>

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

--00000000000018f6a2056a4876c8--

.

------=_Part_9487_101292664.1524237684154
Content-Type: multipart/alternative;
 boundary="----=_Part_9488_1935128231.1524237684154"

------=_Part_9488_1935128231.1524237684154
Content-Type: text/plain; charset="UTF-8"

On Friday, April 20, 2018 at 10:25:37 AM UTC-4, Matt Calabrese wrote:
>
> On Thu, Apr 19, 2018 at 4:04 AM Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:
>> > Is there any way to "fix" std::function's function call operator to not
>> > throw on empty, but make it UB? It expands to quite some more code than
>> > should be necessary to call a std::function, even if your own code's
>> > precondition is that the object is not empty. This is in violation of
>> > DPFWYDN (don't pay for what you don't use), because there's no way to
>> > call the function without the check.
>>
>> Maybe this can be done exactly like std::vector's at() and operator[]:
>> add a
>> new member, like call(...) or invoke(...).
>>
>> Then the operator()(Args... args) becomes:
>>
>>         if (!*this)
>>                 throw something();
>>         return call(args...);
>>
>
> I know that we do this in a couple of places in the standard library, but
> I consider it a mistake and a symptom of us just not coming to consensus on
> what makes for a good contract. It'd be disappointing if every time we were
> to encounter a situation like this we'd have two versions of the same
> function.
>

But that's kinda what we need. Different people have different needs, and
if we want a standard, then we need to cast a wide net. Some people
genuinely want that exception, and they don't want to have to write some
wrapper function just to use a standard library interface. Some people
genuinely cannot accept the cost of the test (let alone the exception), and
there's no way to have a wrapper work around such a test.

Neither interface alone can satiate both sides. I really don't see the
problem in allowing each side to get what they need. C++ is not running out
of functions, after all.


> Thankfully we don't do it *too* much right now, but the places that we do
> aren't particularly special and it's an unfortunate precedent.
>

--
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/c9c7ae64-52f7-45ba-af14-8866e32e4b0c%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 20, 2018 at 10:25:37 AM UTC-4, Matt Calab=
rese 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"><d=
iv class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Apr 19, 2018 at 4:04 AM T=
hiago Macieira &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"87ChWQ7xCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">thi...@macieira.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:<br=
>
&gt; Is there any way to &quot;fix&quot; std::function&#39;s function call =
operator to not<br>
&gt; throw on empty, but make it UB? It expands to quite some more code tha=
n<br>
&gt; should be necessary to call a std::function, even if your own code&#39=
;s<br>
&gt; precondition is that the object is not empty. This is in violation of<=
br>
&gt; DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39;=
s no way to<br>
&gt; call the function without the check.<br>
<br>
Maybe this can be done exactly like std::vector&#39;s at() and operator[]: =
add a <br>
new member, like call(...) or invoke(...).<br>
<br>
Then the operator()(Args... args) becomes:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!*this)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw something();<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return call(args...);<br></blockquote><div><br>=
</div><div>I know that we do this in a couple of places in the standard lib=
rary, but I consider it a mistake and a symptom of us just not coming to co=
nsensus on what makes for a good contract. It&#39;d be disappointing if eve=
ry time we were to encounter a situation like this we&#39;d have two versio=
ns of the same function.</div></div></div></blockquote><div><br>But that&#3=
9;s kinda what we need. Different people have different needs, and if we wa=
nt a standard, then we need to cast a wide net. Some people genuinely want =
that exception, and they don&#39;t want to have to write some wrapper funct=
ion just to use a standard library interface. Some people genuinely cannot =
accept the cost of the test (let alone the exception), and there&#39;s no w=
ay to have a wrapper work around such a test.<br><br>Neither interface alon=
e can satiate both sides. I really don&#39;t see the problem in allowing ea=
ch side to get what they need. C++ is not running out of functions, after a=
ll.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div class=3D"gmail_quote"><div>Thankfully we don&#39;t do it *too* m=
uch right now, but the places that we do aren&#39;t particularly special an=
d it&#39;s an unfortunate precedent.<br></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c9c7ae64-52f7-45ba-af14-8866e32e4b0c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c9c7ae64-52f7-45ba-af14-8866e32e4b0c=
%40isocpp.org</a>.<br />

------=_Part_9488_1935128231.1524237684154--

------=_Part_9487_101292664.1524237684154--

.

------=_Part_9191_179955089.1524238919520
Content-Type: multipart/alternative;
 boundary="----=_Part_9192_2079012763.1524238919520"

------=_Part_9192_2079012763.1524238919520
Content-Type: text/plain; charset="UTF-8"



On Friday, April 20, 2018 at 9:25:37 AM UTC-5, Matt Calabrese wrote:
>
> On Thu, Apr 19, 2018 at 4:04 AM Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:
>> > Is there any way to "fix" std::function's function call operator to not
>> > throw on empty, but make it UB? It expands to quite some more code than
>> > should be necessary to call a std::function, even if your own code's
>> > precondition is that the object is not empty. This is in violation of
>> > DPFWYDN (don't pay for what you don't use), because there's no way to
>> > call the function without the check.
>>
>> Maybe this can be done exactly like std::vector's at() and operator[]:
>> add a
>> new member, like call(...) or invoke(...).
>>
>> Then the operator()(Args... args) becomes:
>>
>>         if (!*this)
>>                 throw something();
>>         return call(args...);
>>
>
> I know that we do this in a couple of places in the standard library, but
> I consider it a mistake and a symptom of us just not coming to consensus on
> what makes for a good contract. It'd be disappointing if every time we were
> to encounter a situation like this we'd have two versions of the same
> function. Thankfully we don't do it *too* much right now, but the places
> that we do aren't particularly special and it's an unfortunate precedent.
>

Especially in this case where we can't exactly have two different
operator()s...

Oh wait, let's add operator()(std::no_throw_t, Args...)!

/s

--
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/1793f2e5-2939-412e-9f68-1a4e8f40f525%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, April 20, 2018 at 9:25:37 AM UTC-5, Mat=
t Calabrese 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"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Apr 19, 2018 at 4:=
04 AM Thiago Macieira &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"87ChWQ7xCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">thi...@macieira.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc =
wrote:<br>
&gt; Is there any way to &quot;fix&quot; std::function&#39;s function call =
operator to not<br>
&gt; throw on empty, but make it UB? It expands to quite some more code tha=
n<br>
&gt; should be necessary to call a std::function, even if your own code&#39=
;s<br>
&gt; precondition is that the object is not empty. This is in violation of<=
br>
&gt; DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39;=
s no way to<br>
&gt; call the function without the check.<br>
<br>
Maybe this can be done exactly like std::vector&#39;s at() and operator[]: =
add a <br>
new member, like call(...) or invoke(...).<br>
<br>
Then the operator()(Args... args) becomes:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!*this)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw something();<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return call(args...);<br></blockquote><div><br>=
</div><div>I know that we do this in a couple of places in the standard lib=
rary, but I consider it a mistake and a symptom of us just not coming to co=
nsensus on what makes for a good contract. It&#39;d be disappointing if eve=
ry time we were to encounter a situation like this we&#39;d have two versio=
ns of the same function. Thankfully we don&#39;t do it *too* much right now=
, but the places that we do aren&#39;t particularly special and it&#39;s an=
 unfortunate precedent.<br></div></div></div></blockquote><div><br></div><d=
iv>Especially in this case where we can&#39;t exactly have two different op=
erator()s...=C2=A0</div><div><br></div><div>Oh wait, let&#39;s add operator=
()(std::no_throw_t, Args...)!</div><div><br></div><div>/s</div></div>

<p></p>

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

------=_Part_9192_2079012763.1524238919520--

------=_Part_9191_179955089.1524238919520--

.

--000000000000e7d8d5056a49b782
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 20, 2018 at 11:21 AM Nicol Bolas <jmckesson@gmail.com> wrote:

> But that's kinda what we need. Different people have different needs, and
> if we want a standard, then we need to cast a wide net. Some people
> genuinely want that exception, and they don't want to have to write some
> wrapper function just to use a standard library interface.
>

What makes this precondition more special than other preconditions? We have
a whole lot of functions with preconditions -- why are people okay with
those functions not explicitly checking input values and throwing (serious
question)?

I don't think it's too much to tell a user to write a wrapper to throw if
they really want it, but I'd argue that a desire for that is pretty much
always a mistake anyway. When throwing in places like these either it is
because of one of two problematic scenarios. 1) the user called the
function *thinking* that the std::function was not empty (in other words,
they thought, based on their expected program invariants, that the object
*was not* null, in which case an exception propagation will not provide a
way to "fix" that. Or, it could be 2) they did not know if the
std::function object was empty and they are relying on an exception to tell
them, in which case they are using the exception as normal control flow.

The reason I see people advocate exceptions in case #1 is because they are
"against" UB, but they miss the fact that if their assumptions about their
program's state do not actually hold, then they are already in a place
where they cannot possibly know that they can safely recover. If they were
concerned about safety, the best they could do is cause some form of
termination, such as abort or quick_exit with at most an at_quick_exit
registered.

--
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/CANh8DE%3D_i4juH6Z1RxFNOuHHRERr886r2pNcOV-aP0cKoX%3DzWg%40mail.gmail.com.

--000000000000e7d8d5056a49b782
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Apr 20=
, 2018 at 11:21 AM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com" t=
arget=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>But that&#39;s kinda what we need. D=
ifferent people have different needs, and if we want a standard, then we ne=
ed to cast a wide net. Some people genuinely want that exception, and they =
don&#39;t want to have to write some wrapper function just to use a standar=
d library interface.</div></div></blockquote><div><br></div><div>What makes=
 this precondition more special than other preconditions? We have a whole l=
ot of functions with preconditions -- why are people okay with those functi=
ons not explicitly checking input values and throwing (serious question)?</=
div><div><br></div><div>I don&#39;t think it&#39;s too much to tell a user =
to write a wrapper to throw if they really want it, but I&#39;d argue that =
a desire for that is pretty much always a mistake anyway. When throwing in =
places like these either it is because of one of two problematic scenarios.=
 1) the user called the function *thinking* that the std::function was not =
empty (in other words, they thought, based on their expected program invari=
ants, that the object *was not* null, in which case an exception propagatio=
n will not provide a way to &quot;fix&quot; that. Or, it could be 2) they d=
id not know if the std::function object was empty and they are relying on a=
n exception to tell them, in which case they are using the exception as nor=
mal control flow.</div><div><br></div><div>The reason I see people advocate=
 exceptions in case #1 is because they are &quot;against&quot; UB, but they=
 miss the fact that if their assumptions about their program&#39;s state do=
 not actually hold, then they are already in a place where they cannot poss=
ibly know that they can safely recover. If they were concerned about safety=
, the best they could do is cause some form of termination, such as abort o=
r quick_exit with at most an at_quick_exit registered.</div></div></div>

<p></p>

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

--000000000000e7d8d5056a49b782--

.

On 20 April 2018 at 18:55, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> I don't think it's too much to tell a user to write a wrapper to throw if
> they really want it, but I'd argue that a desire for that is pretty much
> always a mistake anyway. When throwing in places like these either it is
> because of one of two problematic scenarios. 1) the user called the function
> *thinking* that the std::function was not empty (in other words, they
> thought, based on their expected program invariants, that the object *was
> not* null, in which case an exception propagation will not provide a way to
> "fix" that. Or, it could be 2) they did not know if the std::function object
> was empty and they are relying on an exception to tell them, in which case
> they are using the exception as normal control flow.
>
> The reason I see people advocate exceptions in case #1 is because they are
> "against" UB, but they miss the fact that if their assumptions about their
> program's state do not actually hold, then they are already in a place where
> they cannot possibly know that they can safely recover. If they were
> concerned about safety, the best they could do is cause some form of
> termination, such as abort or quick_exit with at most an at_quick_exit
> registered.

There are situations where there is sufficient information to recover,
and there are logic errors that are recoverable
from. I have both seen and written systems where small-scale logic
errors are situations where e.g. plugins
are 'confused', but do not leak anything and can be just
disabled/stopped. One practical example of that was
a video format plugin that didn't handle a certain state transition
properly, and could not play videos properly
in a certain window configuration. It's perfectly ok for such a plugin
to throw, saying "I'm confused", and have the
application deal with the situation, rather than crashing a whole
image/video gallery just because one particular
video plugin decided it can't operate.

So no, advocating exceptions in such situations is not done because of
some dogma against UB, it's done for
practical reasons, avoiding dogma about one error handling strategy
fitting every conceivable situation,
and understanding that partial failure even because of logic errors
can be better than aborting.

And again, as far as safety is concerned, there are systems where
aborting is the most dangerous thing you
can do, causing actual danger to the user.

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

.

------=_Part_9494_406583499.1524241789329
Content-Type: multipart/alternative;
 boundary="----=_Part_9495_551150062.1524241789329"

------=_Part_9495_551150062.1524241789329
Content-Type: text/plain; charset="UTF-8"

On Friday, April 20, 2018 at 11:41:59 AM UTC-4, Barry Revzin wrote:
>
> On Friday, April 20, 2018 at 9:25:37 AM UTC-5, Matt Calabrese wrote:
>>
>> On Thu, Apr 19, 2018 at 4:04 AM Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:
>>> > Is there any way to "fix" std::function's function call operator to not
>>> > throw on empty, but make it UB? It expands to quite some more code than
>>> > should be necessary to call a std::function, even if your own code's
>>> > precondition is that the object is not empty. This is in violation of
>>> > DPFWYDN (don't pay for what you don't use), because there's no way to
>>> > call the function without the check.
>>>
>>> Maybe this can be done exactly like std::vector's at() and operator[]:
>>> add a
>>> new member, like call(...) or invoke(...).
>>>
>>> Then the operator()(Args... args) becomes:
>>>
>>>         if (!*this)
>>>                 throw something();
>>>         return call(args...);
>>>
>>
>> I know that we do this in a couple of places in the standard library, but
>> I consider it a mistake and a symptom of us just not coming to consensus on
>> what makes for a good contract. It'd be disappointing if every time we were
>> to encounter a situation like this we'd have two versions of the same
>> function. Thankfully we don't do it *too* much right now, but the places
>> that we do aren't particularly special and it's an unfortunate precedent.
>>
>
> Especially in this case where we can't exactly have two different
> operator()s...
>
> Oh wait, let's add operator()(std::no_throw_t, Args...)!
>

That may be sarcasm to you, but it seems like a good solution to me. Well,
you'd have to create a different type (to avoid breaking existing code that
passes `no_throw_t` in the first parameter), but the general idea is a good
one.

Yes, this is backwards; the standard usually makes named functions throw
while giving narrow contracts to operators. But given that we already
bogeyed that hole, this is at least a serviceable fix.


>
> /s
>

--
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/5e14a32a-6647-4428-a707-9c2833385983%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 20, 2018 at 11:41:59 AM UTC-4, Barry Revz=
in 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">On F=
riday, April 20, 2018 at 9:25:37 AM UTC-5, Matt Calabrese 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"><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Thu, Apr 19, 2018 at 4:04 AM Thiago Macieira &lt;<a rel=
=3D"nofollow">thi...@macieira.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:<br=
>
&gt; Is there any way to &quot;fix&quot; std::function&#39;s function call =
operator to not<br>
&gt; throw on empty, but make it UB? It expands to quite some more code tha=
n<br>
&gt; should be necessary to call a std::function, even if your own code&#39=
;s<br>
&gt; precondition is that the object is not empty. This is in violation of<=
br>
&gt; DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39;=
s no way to<br>
&gt; call the function without the check.<br>
<br>
Maybe this can be done exactly like std::vector&#39;s at() and operator[]: =
add a <br>
new member, like call(...) or invoke(...).<br>
<br>
Then the operator()(Args... args) becomes:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!*this)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw something();<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return call(args...);<br></blockquote><div><br>=
</div><div>I know that we do this in a couple of places in the standard lib=
rary, but I consider it a mistake and a symptom of us just not coming to co=
nsensus on what makes for a good contract. It&#39;d be disappointing if eve=
ry time we were to encounter a situation like this we&#39;d have two versio=
ns of the same function. Thankfully we don&#39;t do it *too* much right now=
, but the places that we do aren&#39;t particularly special and it&#39;s an=
 unfortunate precedent.<br></div></div></div></blockquote><div><br></div><d=
iv>Especially in this case where we can&#39;t exactly have two different op=
erator()s...=C2=A0</div><div><br></div><div>Oh wait, let&#39;s add operator=
()(std::no_throw_t, Args...)!</div></div></blockquote><div><br>That may be =
sarcasm to you, but it seems like a good solution to me. Well, you&#39;d ha=
ve to create a different type (to avoid breaking existing code that passes =
`no_throw_t` in the first parameter), but the general idea is a good one.<b=
r><br>Yes, this is backwards; the standard usually makes named functions th=
row while giving narrow contracts to operators. But given that we already b=
ogeyed that hole, this is at least a serviceable fix.<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div=
>/s</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5e14a32a-6647-4428-a707-9c2833385983%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e14a32a-6647-4428-a707-9c2833385983=
%40isocpp.org</a>.<br />

------=_Part_9495_551150062.1524241789329--

------=_Part_9494_406583499.1524241789329--

.

------=_Part_9708_735490337.1524243236063
Content-Type: multipart/alternative;
 boundary="----=_Part_9709_1200389119.1524243236063"

------=_Part_9709_1200389119.1524243236063
Content-Type: text/plain; charset="UTF-8"



On Friday, April 20, 2018 at 6:29:49 PM UTC+2, Nicol Bolas wrote:
>
> On Friday, April 20, 2018 at 11:41:59 AM UTC-4, Barry Revzin wrote:
>>
>> On Friday, April 20, 2018 at 9:25:37 AM UTC-5, Matt Calabrese wrote:
>>>
>>> On Thu, Apr 19, 2018 at 4:04 AM Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>>
>>>> On Wednesday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:
>>>> > Is there any way to "fix" std::function's function call operator to
>>>> not
>>>> > throw on empty, but make it UB? It expands to quite some more code
>>>> than
>>>> > should be necessary to call a std::function, even if your own code's
>>>> > precondition is that the object is not empty. This is in violation of
>>>> > DPFWYDN (don't pay for what you don't use), because there's no way to
>>>> > call the function without the check.
>>>>
>>>> Maybe this can be done exactly like std::vector's at() and operator[]:
>>>> add a
>>>> new member, like call(...) or invoke(...).
>>>>
>>>> Then the operator()(Args... args) becomes:
>>>>
>>>>         if (!*this)
>>>>                 throw something();
>>>>         return call(args...);
>>>>
>>>
>>> I know that we do this in a couple of places in the standard library,
>>> but I consider it a mistake and a symptom of us just not coming to
>>> consensus on what makes for a good contract. It'd be disappointing if every
>>> time we were to encounter a situation like this we'd have two versions of
>>> the same function. Thankfully we don't do it *too* much right now, but the
>>> places that we do aren't particularly special and it's an unfortunate
>>> precedent.
>>>
>>
>> Especially in this case where we can't exactly have two different
>> operator()s...
>>
>> Oh wait, let's add operator()(std::no_throw_t, Args...)!
>>
>
> That may be sarcasm to you, but it seems like a good solution to me. Well,
> you'd have to create a different type (to avoid breaking existing code that
> passes `no_throw_t` in the first parameter), but the general idea is a good
> one.
>
> Yes, this is backwards; the standard usually makes named functions throw
> while giving narrow contracts to operators. But given that we already
> bogeyed that hole, this is at least a serviceable fix.
>
>
>>
>> /s
>>
>
Another is adding helper function that will return special type that will
call without check:
std::no_throw(f)(a, b, c);

if (f) std::some_algo(a, b, std::no_throw(f));



--
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/548117e2-0fb8-465b-a16a-f1c44fa76e2e%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, April 20, 2018 at 6:29:49 PM UTC+2, Nic=
ol Bolas 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=
">On Friday, April 20, 2018 at 11:41:59 AM UTC-4, Barry Revzin wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, April 20, 201=
8 at 9:25:37 AM UTC-5, Matt Calabrese wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Th=
u, Apr 19, 2018 at 4:04 AM Thiago Macieira &lt;<a rel=3D"nofollow">thi...@m=
acieira.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wedne=
sday, 18 April 2018 01:33:45 PDT Mutz, Marc wrote:<br>
&gt; Is there any way to &quot;fix&quot; std::function&#39;s function call =
operator to not<br>
&gt; throw on empty, but make it UB? It expands to quite some more code tha=
n<br>
&gt; should be necessary to call a std::function, even if your own code&#39=
;s<br>
&gt; precondition is that the object is not empty. This is in violation of<=
br>
&gt; DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39;=
s no way to<br>
&gt; call the function without the check.<br>
<br>
Maybe this can be done exactly like std::vector&#39;s at() and operator[]: =
add a <br>
new member, like call(...) or invoke(...).<br>
<br>
Then the operator()(Args... args) becomes:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!*this)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw something();<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return call(args...);<br></blockquote><div><br>=
</div><div>I know that we do this in a couple of places in the standard lib=
rary, but I consider it a mistake and a symptom of us just not coming to co=
nsensus on what makes for a good contract. It&#39;d be disappointing if eve=
ry time we were to encounter a situation like this we&#39;d have two versio=
ns of the same function. Thankfully we don&#39;t do it *too* much right now=
, but the places that we do aren&#39;t particularly special and it&#39;s an=
 unfortunate precedent.<br></div></div></div></blockquote><div><br></div><d=
iv>Especially in this case where we can&#39;t exactly have two different op=
erator()s...=C2=A0</div><div><br></div><div>Oh wait, let&#39;s add operator=
()(std::no_throw_t, Args...)!</div></div></blockquote><div><br>That may be =
sarcasm to you, but it seems like a good solution to me. Well, you&#39;d ha=
ve to create a different type (to avoid breaking existing code that passes =
`no_throw_t` in the first parameter), but the general idea is a good one.<b=
r><br>Yes, this is backwards; the standard usually makes named functions th=
row while giving narrow contracts to operators. But given that we already b=
ogeyed that hole, this is at least a serviceable fix.<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>/s</=
div></div></blockquote></div></blockquote><div><br>Another is adding helper=
 function that will return special type that will call without check:<br><d=
iv style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;=
" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">no_throw</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">)(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br>if (f) std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">some_algo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">no_throw</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"></span></code>)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">;<br></span></div></code></div><=
br>=C2=A0<br></div></div>

<p></p>

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

------=_Part_9709_1200389119.1524243236063--

------=_Part_9708_735490337.1524243236063--

.

--000000000000c8c217056a4b21cd
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 20, 2018 at 12:04 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> One practical example of that was
> a video format plugin that didn't handle a certain state transition
> properly, and could not play videos properly
> in a certain window configuration. It's perfectly ok for such a plugin
> to throw, saying "I'm confused", and have the
> application deal with the situation, rather than crashing a whole
> image/video gallery just because one particular
> video plugin decided it can't operate.
>

I agree that this is fine, but I also do not see the direct relationship
with std::function's operator(). Perhaps I gave the wrong impression from
my previous reply -- I am *not* against exceptions. My view of the
std::function "problem" is that it throws in a place where I would consider
it a precondition violation. My interpretation of the underlying issue for
the std::function operator() case (and other similar cases in the standard
library) is that we do not have clear and consistent rationale for why
something should or should not be a precondition (in other words, when to
have wide contracts and when to have narrow contracts).

The approximation that I tend to personally use is that wide contracts are
often appropriate when part of the function's purpose is to directly
operate on user input. I would consider your plugin example as falling
under this kind of case, assuming I understood your situation correctly. As
well, a wide contract can make sense for input that cannot easily be
guaranteed to be in a sensible state by the caller, but can be checked
during operation in the implementation (for instance, a function that
parses a string as C++).

In the case of a narrow contract, I would not want a throw on a violation,
since the caller has not met that end of the contract (though perhaps the
contracts language feature will let people throw anyway if they choose,
even though I would not recommend actually doing that for reasons already
mentioned).

In the case of a wide contract, I think that whether a function chooses to
throw or to return something like the proposed std::expected is somewhat
subjective and depends both on practical concerns (such as the
implementation of each of these mechanisms) as well as more subjective
concerns, such as what the library author chooses to represent as the
output space of the function, in the sense that a "std::expected" result
expands the output space, whereas an exception keeps the output space
restricted to those of a "successful" execution.

Ultimately, because std::function's operator() is not some direct interface
operating on user input, it goes against at least my personal internal
guidelines for a wide contract (it would be nice if we at least had *some*
explicit guideline here for the standard if possible. I can start such a
paper, but I'm not at all optimistic that it would be well received unless
there were collaborators from people who have different views and we
actually were to come to some kind of agreement.

If we were to give std::function's operator() a narrow contract (that is,
assume that we have a time machine), then if and when we get contracts as a
language feature, people would be able to get more direct control of what
they want to happen on a contract violation. I think that this kind of
direction is somewhat closer to a solution that appeases multiple parties
without having duplicate interfaces.

On Fri, Apr 20, 2018 at 12:04 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> So no, advocating exceptions in such situations is not done because of
> some dogma against UB, it's done for
> practical reasons, avoiding dogma about one error handling strategy
> fitting every conceivable situation,
> and understanding that partial failure even because of logic errors
> can be better than aborting.
>

I think we are having something of a mismatch in our terminology. What you
are referring to as a logic error I would not consider a logic error.
Despite the context being exceptions, I am also not particularly concerned
about one error strategy vs another -- I'm more concerned about what should
or should not be considered a contract violation to begin with.

On Fri, Apr 20, 2018 at 12:04 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> And again, as far as safety is concerned, there are systems where
> aborting is the most dangerous thing you
> can do, causing actual danger to the user.


It depends on your "failure" and your system, yes. From personal
experience, I used to work in robotics where actual operator safety is a
concern. quick_exit from a controlling process was the safe thing to do if
we detected that our expected invariants were violated (detected, for
instance, via a checked precondition). I do not state that some form of
termination is the proper response to all "failures", but rather, that
proper categorization of what is or is not a failure is why we are having
problems with defining our interfaces. Until we come up with some kind of
rule-book, if such a rule-book can even exist, I predict that we will just
keep running into situations like the std::function operator() case.
Explicitly providing throwing and non-throwing versions for each does not
seem ideal.

--
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/CANh8DEnDArdT-yXUbTCM5ZwiUC1B_A%3DB-ob4N6mywq%3DwUTdN%2BQ%40mail.gmail.com.

--000000000000c8c217056a4b21cd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Apr 20=
, 2018 at 12:04 PM Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilaine=
n@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">One practical example of that was<br>
a video format plugin that didn&#39;t handle a certain state transition<br>
properly, and could not play videos properly<br>
in a certain window configuration. It&#39;s perfectly ok for such a plugin<=
br>
to throw, saying &quot;I&#39;m confused&quot;, and have the<br>
application deal with the situation, rather than crashing a whole<br>
image/video gallery just because one particular<br>
video plugin decided it can&#39;t operate.<br></blockquote><div><br></div><=
div>I agree that this is fine, but I also do not see the direct relationshi=
p with std::function&#39;s operator(). Perhaps I gave the wrong impression =
from my previous reply -- I am <i>not</i>=C2=A0against exceptions. My view =
of the std::function &quot;problem&quot; is that it throws in a place where=
 I would consider it a precondition violation. My interpretation of the und=
erlying issue for the std::function operator() case (and other similar case=
s in the standard library) is that we do not have clear and consistent rati=
onale for why something should or should not be a precondition (in other wo=
rds, when to have wide contracts and when to have narrow contracts).</div><=
div><br></div><div>The approximation that I tend to personally use is that =
wide contracts are often appropriate when part of the function&#39;s purpos=
e is to directly operate on user input. I would consider your plugin exampl=
e as falling under this kind of case, assuming I understood your situation =
correctly. As well, a wide contract can make sense for input that cannot ea=
sily be guaranteed to be in a sensible state by the caller, but can be chec=
ked during operation in the implementation (for instance, a function that p=
arses a string as C++).</div><div><br></div><div>In the case of a narrow co=
ntract, I would not want a throw on a violation, since the caller has not m=
et that end of the contract (though perhaps the contracts language feature =
will let people throw anyway if they choose, even though I would not recomm=
end actually doing that for reasons already mentioned).</div><div><br></div=
><div>In the case of a wide contract, I think that whether a function choos=
es to throw or to return something like the proposed std::expected is somew=
hat subjective and depends both on practical concerns (such as the implemen=
tation of each of these mechanisms) as well as more subjective concerns, su=
ch as what the library author chooses to represent as the output space of t=
he function, in the sense that a &quot;std::expected&quot; result expands t=
he output space, whereas an exception keeps the output space restricted to =
those of a &quot;successful&quot; execution.</div><div><br></div><div></div=
><div>Ultimately, because std::function&#39;s operator() is not some direct=
 interface operating on user input, it goes against at least my personal in=
ternal guidelines for a wide contract (it would be nice if we at least had =
*some* explicit guideline here for the standard if possible. I can start su=
ch a paper, but I&#39;m not at all optimistic that it would be well receive=
d unless there were collaborators from people who have different views and =
we actually were to come to some kind of agreement.</div><div><br></div><di=
v>If we were to give std::function&#39;s operator() a narrow contract (that=
 is, assume that we have a time machine), then if and when we get contracts=
 as a language feature, people would be able to get more direct control of =
what they want to happen on a contract violation. I think that this kind of=
 direction is somewhat closer to a solution that appeases multiple parties =
without having duplicate interfaces.</div><div><br></div><div><span style=
=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:no=
rmal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400=
;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text=
-decoration-style:initial;text-decoration-color:initial;float:none;display:=
inline">On Fri, Apr 20, 2018 at 12:04 PM Ville Voutilainen &lt;<a href=3D"m=
ailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrot=
e:</span></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
So no, advocating exceptions in such situations is not done because of<br>
some dogma against UB, it&#39;s done for<br>
practical reasons, avoiding dogma about one error handling strategy<br>
fitting every conceivable situation,<br>
and understanding that partial failure even because of logic errors<br>
can be better than aborting.<br></blockquote><div><br></div><div>I think we=
 are having something of a mismatch in our terminology. What you are referr=
ing to as a logic error I would not consider a logic error. Despite the con=
text being exceptions, I am also not particularly concerned about one error=
 strategy vs another -- I&#39;m more concerned about what should or should =
not be considered a contract violation to begin with.</div><div><br></div><=
div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13p=
x;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;=
font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(25=
5,255,255);text-decoration-style:initial;text-decoration-color:initial;floa=
t:none;display:inline">On Fri, Apr 20, 2018 at 12:04 PM Ville Voutilainen &=
lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.c=
om</a>&gt; wrote:</span></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And again, as far as safety is concerned, there are systems where<br>
aborting is the most dangerous thing you<br>
can do, causing actual danger to the user.</blockquote><div><br></div><div>=
It depends on your &quot;failure&quot; and your system, yes. From personal =
experience, I used to work in robotics where actual operator safety is a co=
ncern. quick_exit from a controlling process was the safe thing to do if we=
 detected that our expected invariants were violated (detected, for instanc=
e, via a checked precondition). I do not state that some form of terminatio=
n is the proper response to all &quot;failures&quot;, but rather, that prop=
er categorization of what is or is not a failure is why we are having probl=
ems with defining our interfaces. Until we come up with some kind of rule-b=
ook, if such a rule-book can even exist, I predict that we will just keep r=
unning into situations like the std::function operator() case. Explicitly p=
roviding throwing and non-throwing versions for each does not seem ideal.</=
div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnDArdT-yXUbTCM5ZwiUC1B_A%3DB-o=
b4N6mywq%3DwUTdN%2BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnDAr=
dT-yXUbTCM5ZwiUC1B_A%3DB-ob4N6mywq%3DwUTdN%2BQ%40mail.gmail.com</a>.<br />

--000000000000c8c217056a4b21cd--

.

On 04/20/18 19:04, Ville Voutilainen wrote:
> On 20 April 2018 at 18:55, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>> I don't think it's too much to tell a user to write a wrapper to throw if
>> they really want it, but I'd argue that a desire for that is pretty much
>> always a mistake anyway. When throwing in places like these either it is
>> because of one of two problematic scenarios. 1) the user called the function
>> *thinking* that the std::function was not empty (in other words, they
>> thought, based on their expected program invariants, that the object *was
>> not* null, in which case an exception propagation will not provide a way to
>> "fix" that. Or, it could be 2) they did not know if the std::function object
>> was empty and they are relying on an exception to tell them, in which case
>> they are using the exception as normal control flow.
>>
>> The reason I see people advocate exceptions in case #1 is because they are
>> "against" UB, but they miss the fact that if their assumptions about their
>> program's state do not actually hold, then they are already in a place where
>> they cannot possibly know that they can safely recover. If they were
>> concerned about safety, the best they could do is cause some form of
>> termination, such as abort or quick_exit with at most an at_quick_exit
>> registered.
>
> There are situations where there is sufficient information to recover,
> and there are logic errors that are recoverable
> from. I have both seen and written systems where small-scale logic
> errors are situations where e.g. plugins
> are 'confused', but do not leak anything and can be just
> disabled/stopped. One practical example of that was
> a video format plugin that didn't handle a certain state transition
> properly, and could not play videos properly
> in a certain window configuration. It's perfectly ok for such a plugin
> to throw, saying "I'm confused", and have the
> application deal with the situation, rather than crashing a whole
> image/video gallery just because one particular
> video plugin decided it can't operate.
>
> So no, advocating exceptions in such situations is not done because of
> some dogma against UB, it's done for
> practical reasons, avoiding dogma about one error handling strategy
> fitting every conceivable situation,
> and understanding that partial failure even because of logic errors
> can be better than aborting.
>
> And again, as far as safety is concerned, there are systems where
> aborting is the most dangerous thing you
> can do, causing actual danger to the user.

This is a question of reasonable balance between relying on
preconditions to hold and not trusting the environment. In the projects
I worked in, we usually relied on preconditions within a reasonably
self-contained module or library and not trust the input from outside of
the module, be that function parameters or data from external sources
like files or network.

Finding a good balance can be difficult but I guess the best way to do
it is by weighting the benefits from a runtime check compared to its
cost. A library, or a media plugin like in your example, should be
reasonably resilient to incorrect input and report errors, and checking
parameters for correctness will likely not be very expensive compared to
the other useful work that the library perform. OTOH, an exception from
a small and generic component like std::function is not really helpful
and the check can have a more significant cost.

You also have to consider the usefulness of the diagnostics that the
component can provide in response to invalid input. For example, an
exception from a library could provide an insight on what exactly is
wrong and what is expected, with more specifics to the library domain
and API, compared to the generic exception that operator() would throw.
For this reason I find myself almost never relying on exceptions thrown
by the standard library, even where I could - I just want to have a more
meaningful diagnostics in case of errors.

--
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/c00434e8-1bb3-1258-c491-60f48b996f66%40gmail.com.

.

On 2018-04-20 19:36, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals wrote:
[...]
> Explicitly
> providing throwing and non-throwing versions for each does not seem
> ideal.

True. Esp. in the light of YAFRM[1] which will prompt the next guy to
request

   std::expected<R> function<R(Args...)>::operator(Args...args) {
      if (bool(*this)) return call(forward<Args>(args)...);
      else return unexpected(~~~);
   }

C++ vocabulary types should implement the hard bits, not meddle with
policy. So, std::function should deal with the type erasure of
callables, and state non-emptiness as a precondition for calling op().
People can then write wrappers that throw exceptions, or return
std::expected, as they feel is right for them.

That this should be controversial is a bit surprising to me. After all,
that is the only way to meet don't-pay-for-what-you-don't-use...

[1] Yet Another Failure Reporting Mechanism

Thanks,
Marc

--
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/270a2066c7262cad19645bd452af4f1b%40kdab.com.

.

--000000000000129334056a4dbc0b
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 20, 2018 at 3:00 PM Mutz, Marc <marc@kdab.com> wrote:

> That this should be controversial is a bit surprising to me. After all,
> that is the only way to meet don't-pay-for-what-you-don't-use...
>

At least some part of it is genuinely because a subset of developers
including some who participate in the committee (I know, not you,
Ville ;)) very
explicitly do not want any new UB, including with respect to preconditions
-- such views regarding UB were even expressed in this very thread. It is
sometimes even given as the rationale for why people want something to
throw. The reality is, people desire this so strongly that they are willing
to sacrifice "don't pay for what you don't use". This is partly why I
really think we need to focus more directly on what should and should not
be a precondition rather than any specific reporting or recovery strategy.
If the contracts language feature pulls through and remains sufficiently
customizable, my hope is that, at the very least, these types of "I don't
want UB" concerns go away, since users can get what they want without
impacting the contract itself.

--
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/CANh8DEkTF6iV5wSSQv10BPcseK5JbXhtWqZQ9Nse4mXWHH-9xw%40mail.gmail.com.

--000000000000129334056a4dbc0b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Apr 20=
, 2018 at 3:00 PM Mutz, Marc &lt;<a href=3D"mailto:marc@kdab.com">marc@kdab=
..com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That this shoul=
d be controversial is a bit surprising to me. After all, <br>
that is the only way to meet don&#39;t-pay-for-what-you-don&#39;t-use...<br=
></blockquote><div><br></div><div>At least some part of it is genuinely bec=
ause a subset of developers including some who participate in the committee=
=C2=A0<span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:1=
3px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norma=
l;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;te=
xt-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(=
255,255,255);text-decoration-style:initial;text-decoration-color:initial;fl=
oat:none;display:inline">(I know, not you, Ville ;))=C2=A0</span>very expli=
citly do not want any new UB, including with respect to preconditions -- su=
ch views regarding UB were even expressed in this very thread. It is someti=
mes even given as the rationale for why people want something to throw. The=
 reality is, people desire this=C2=A0so strongly that they are willing to s=
acrifice &quot;don&#39;t pay for what you don&#39;t use&quot;. This is part=
ly why I really think we need to focus more directly on what should and sho=
uld not be a precondition rather than any specific reporting or recovery st=
rategy. If the contracts language feature pulls through and remains suffici=
ently customizable, my hope is that, at the very least, these types of &quo=
t;I don&#39;t want UB&quot; concerns go away, since users can get what they=
 want without impacting the contract itself.</div></div></div>

<p></p>

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

--000000000000129334056a4dbc0b--

.

------=_Part_3193_385664016.1524334126226
Content-Type: multipart/alternative;
 boundary="----=_Part_3194_1321606624.1524334126226"

------=_Part_3194_1321606624.1524334126226
Content-Type: text/plain; charset="UTF-8"

On Friday, April 20, 2018 at 3:00:09 PM UTC-4, Mutz, Marc wrote:
>
> On 2018-04-20 19:36, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals wrote:
> [...]
> > Explicitly
> > providing throwing and non-throwing versions for each does not seem
> > ideal.
>
> True. Esp. in the light of YAFRM[1] which will prompt the next guy to
> request
>
>    std::expected<R> function<R(Args...)>::operator(Args...args) {
>       if (bool(*this)) return call(forward<Args>(args)...);
>       else return unexpected(~~~);
>    }
>
> C++ vocabulary types should implement the hard bits, not meddle with
> policy. So, std::function should deal with the type erasure of
> callables, and state non-emptiness as a precondition for calling op().
> People can then write wrappers that throw exceptions, or return
> std::expected, as they feel is right for them.
>

Vocabulary types are supposed to be types that you just take off the shelf
and use as is. If you have to write wrappers to use them "properly", then
they're *not* "vocabulary types", are they? That's why having the "wrapper"
built into the type makes sense.

--
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/e4c88b8f-eacf-4943-94a6-7fbe20c504fb%40isocpp.org.

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

<div dir=3D"ltr">On Friday, April 20, 2018 at 3:00:09 PM UTC-4, Mutz, Marc =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2018-04-20 19:36, &#3=
9;Matt Calabrese&#39; via ISO C++ Standard - Future=20
<br>Proposals wrote:
<br>[...]
<br>&gt; Explicitly
<br>&gt; providing throwing and non-throwing versions for each does not see=
m
<br>&gt; ideal.
<br>
<br>True. Esp. in the light of YAFRM[1] which will prompt the next guy to=
=20
<br>request
<br>
<br>=C2=A0 =C2=A0std::expected&lt;R&gt; function&lt;R(Args...)&gt;::<wbr>op=
erator(Args...args) {
<br>=C2=A0 =C2=A0 =C2=A0 if (bool(*this)) return call(forward&lt;Args&gt;(a=
rgs)...);
<br>=C2=A0 =C2=A0 =C2=A0 else return unexpected(~~~);
<br>=C2=A0 =C2=A0}
<br>
<br>C++ vocabulary types should implement the hard bits, not meddle with=20
<br>policy. So, std::function should deal with the type erasure of=20
<br>callables, and state non-emptiness as a precondition for calling op().=
=20
<br>People can then write wrappers that throw exceptions, or return=20
<br>std::expected, as they feel is right for them.
<br></blockquote><div><br>Vocabulary types are supposed to be types that yo=
u just take off the shelf and use as is. If you have to write wrappers to u=
se them &quot;properly&quot;, then they&#39;re <i>not</i> &quot;vocabulary =
types&quot;, are they? That&#39;s why having the &quot;wrapper&quot; built =
into the type makes sense.</div></div>

<p></p>

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

------=_Part_3194_1321606624.1524334126226--

------=_Part_3193_385664016.1524334126226--

.

--001a11478ef68773b4056a63c956
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 19, 2018 at 2:28 AM, Mutz, Marc <marc@kdab.com> wrote:

> On 2018-04-19 04:49, Arthur O'Dwyer wrote:
>
>> On Wednesday, April 18, 2018 at 1:33:49 AM UTC-7, Mutz, Marc wrote:
>>
>> Is there any way to "fix" std::function's function call operator to
>>> not throw on empty, but make it UB?
>>>
>>
>> https://godbolt.org/g/JniNxM [1]
>>
>> Ehh, IMO that's just a (relatively) crappy library implementation. The
>> best way to implement this "default" throwing behavior (just like the
>> best way to implement the "default" throwing behavior for the
>> single-variant std::visit) is to write a function that throws the
>> exception, and make sure that std::function's "default" constructor
>> initializes the object with a pointer to that function.
>> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h#L8=
8
>>
>
> Indeed, that would fix the problem, too. But it has two problems:
>
> 1. How to implement function::operator bool(), then? You can't compare
> function pointers, or vtable addresses: You need to define the
> function/variable inline, because you don't know a-priori which template
> args you're going to be instantiated with. Inline functions and (probably=
)
> variables may be duplicated between executables (SO/DLL/EXE/...), leading
> to the usual problems (here: an empty function<> created in client code
> does not appear empty in out-of-line library code). The inplace_function
> implementation seems to have this problem, btw.
>

Fair point.
The inplace_function `operator bool` does have problems with DLLs, yes:

    explicit constexpr operator bool() const noexcept
    {
        return vtable_ptr_ !=3D
std::addressof(inplace_function_detail::empty_vtable<R, Args...>);
    }

However, the "portable C++" state-of-the-art would have the exact same
problem:

    explicit constexpr operator bool() const noexcept
    {
        return vtable_ptr_->type() !=3D typeid(void);
    }

I don't think inplace_function needs to be the trailblazer in solving the
problems of globals in DLLs.

I think the *best* solution would be to say that "std2::function" should be
never-null, or at least not have a "normal" null state.
Get rid of `operator bool` =E2=80=94 the function object should always have=
 a value
(unless it's default-constructed, maybe, but then why would you be testing
for that default-constructed state?).
If you want a "maybe-function-maybe-nothing" type with an `operator bool`,
you should use "std2::optional<std2::function>" (which can be implemented
with tombstone_traits to be the same size/efficiency as a plain old
never-null std2::function).

By now, you and I might be in violent agreement re: your original point. :)


2. People expect that storing nullptr in a function<> makes it empty, and,
> likewise, that an empty function<> stores nullptr. This is testable with
> function::target(). So you would have to check for and convert from/to
> nullptr at assign and target time. I don't think target() is particularly
> critical here, but having an additional check in the ctor is probably goi=
ng
> to [cost] someone dearly, somewhere, as would the lea instead of the
> nullptr mov.
>

IMHO, `std2::function` probably shouldn't even have a `target() /
target_type()` API.  But std::function's `target_type()` API can be handled
the same way as the `operator()()` API: you just say that an empty
std::function returns typeid(void) from its `target_type()` function.  By
the way, it's typeid(void), not typeid(nullptr_t). Calling `target()` on an
empty `std::function` just gives `nullptr`. So there's no "check for and
convert from/to nullptr at assign and target time" happening here.

And yes, it looks like std::function does check for nullness when you put a
function pointer into it. I don't think std2::function should pay for that
check either. std2::function should assume that if the programmer is
putting a value into it, it's *the value of a real callable*.

    std::function<void()> f;
    f =3D nullptr;  // puts f back into the "empty" state, arguably
ill-advised
    f =3D (void(*)())nullptr;  // puts f back into the "empty" state,
definitely ill-advised, you are paying for a null-check here

inplace_function *does* assume that if you're putting a function-pointer
value into it, it's the value of a callable:
https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h#L182

    inplace_function<void()> f;
    f =3D nullptr;  // puts f back into the "empty" state, arguably
ill-advised
    f =3D (void(*)())nullptr;  // makes f "non-empty" but of course will ha=
ve
UB if you accidentally call it

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BQBpFs7%2BHLuS%3D%3DA0PbN5jrMsNzdswtGw4=
GNf80eCY4xA%40mail.gmail.com.

--001a11478ef68773b4056a63c956
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Apr 19, 2018 at 2:28 AM, Mutz, Marc <span dir=3D"l=
tr">&lt;<a href=3D"mailto:marc@kdab.com" target=3D"_blank">marc@kdab.com</a=
>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex">On 2018-04-19 04:49, Arthur O&#39;Dwyer wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex">
On Wednesday, April 18, 2018 at 1:33:49 AM UTC-7, Mutz, Marc wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><span class=3D"gmail-">Is there any way to &quot;fix&quot;=
 std::function&#39;s function call operator to<br>
not=C2=A0throw on empty, but make it UB?</span><br>
</blockquote>
<br>
<a href=3D"https://godbolt.org/g/JniNxM" rel=3D"noreferrer" target=3D"_blan=
k">https://godbolt.org/g/JniNxM</a> [1]<br>
<br>
Ehh, IMO that&#39;s just a (relatively) crappy library implementation. The<=
br>
best way to implement this &quot;default&quot; throwing behavior (just like=
 the<br>
best way to implement the &quot;default&quot; throwing behavior for the<br>
single-variant std::visit) is to write a function that throws the<br>
exception, and make sure that std::function&#39;s &quot;default&quot; const=
ructor<br>
initializes the object with a pointer to that function.<br>
<a href=3D"https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_funct=
ion.h#L88" rel=3D"noreferrer" target=3D"_blank">https://github.com/WG21-SG1=
4/S<wbr>G14/blob/master/SG14/inplace_f<wbr>unction.h#L88</a><br>
</blockquote>
<br>
Indeed, that would fix the problem, too. But it has two problems:<br>
<br>
1. How to implement function::operator bool(), then? You can&#39;t compare =
function pointers, or vtable addresses: You need to define the function/var=
iable inline, because you don&#39;t know a-priori which template args you&#=
39;re going to be instantiated with. Inline functions and (probably) variab=
les may be duplicated between executables (SO/DLL/EXE/...), leading to the =
usual problems (here: an empty function&lt;&gt; created in client code does=
 not appear empty in out-of-line library code). The inplace_function implem=
entation seems to have this problem, btw.<br></blockquote><div><br></div><d=
iv>Fair point.</div><div>The inplace_function `operator bool` does have pro=
blems with DLLs, yes:</div><div><br></div><div>=C2=A0 =C2=A0 explicit const=
expr operator bool() const noexcept<br></div>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 return vtable_ptr_ !=3D std::addressof(inplace_function_d=
etail::empty_vtable&lt;R, Args...&gt;);<br>=C2=A0 =C2=A0 }</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">However, the &quot;po=
rtable C++&quot; state-of-the-art would have the exact same problem:</div><=
div class=3D"gmail_quote"><div><br></div><div><div class=3D"gmail_quote"><d=
iv>=C2=A0 =C2=A0 explicit constexpr operator bool() const noexcept<br></div=
>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return vtable_ptr_-&gt;type=
() !=3D typeid(void);</div><div class=3D"gmail_quote">=C2=A0 =C2=A0 }</div>=
</div><div><br></div>I don&#39;t think inplace_function needs to be the tra=
ilblazer in solving the problems of globals in DLLs.</div><div class=3D"gma=
il_quote"><br><div>I think the <i><b>best</b></i> solution would be to say =
that &quot;std2::function&quot; should be never-null, or at least not have =
a &quot;normal&quot; null state.</div><div>Get rid of `operator bool` =E2=
=80=94 the function object should always have a value (unless it&#39;s defa=
ult-constructed, maybe, but then why would you be testing for that default-=
constructed state?).</div><div>If you want a &quot;maybe-function-maybe-not=
hing&quot; type with an `operator bool`, you should use &quot;std2::optiona=
l&lt;std2::function&gt;&quot; (which can be implemented with tombstone_trai=
ts to be the same size/efficiency as a plain old never-null std2::function)=
..</div><div><br></div><div>By now, you and I might be in violent agreement =
re: your original point. :)</div><div><br></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex">
2. People expect that storing nullptr in a function&lt;&gt; makes it empty,=
 and, likewise, that an empty function&lt;&gt; stores nullptr. This is test=
able with function::target(). So you would have to check for and convert fr=
om/to nullptr at assign and target time. I don&#39;t think target() is part=
icularly critical here, but having an additional check in the ctor is proba=
bly going to [cost] someone dearly, somewhere, as would the lea instead of =
the nullptr mov.<br></blockquote><div><br></div><div>IMHO, `std2::function`=
 probably shouldn&#39;t even have a `target() / target_type()` API.=C2=A0 B=
ut std::function&#39;s `target_type()` API can be handled the same way as t=
he `operator()()` API: you just say that an empty std::function returns typ=
eid(void) from its `target_type()` function.=C2=A0 By the way, it&#39;s typ=
eid(void), not typeid(nullptr_t). Calling `target()` on an empty `std::func=
tion` just gives `nullptr`. So there&#39;s no &quot;check for and convert f=
rom/to nullptr at assign and target time&quot; happening here.</div><div>=
=C2=A0</div><div>And yes, it looks like std::function does check for nullne=
ss when you put a function pointer into it. I don&#39;t think std2::functio=
n should pay for that check either. std2::function should assume that if th=
e programmer is putting a value into it, it&#39;s <i>the value of a real ca=
llable</i>.</div><div><br></div><div><div>=C2=A0 =C2=A0 std::function&lt;vo=
id()&gt; f;</div><div>=C2=A0 =C2=A0 f =3D nullptr; =C2=A0// puts f back int=
o the &quot;empty&quot; state, arguably ill-advised</div><div>=C2=A0 =C2=A0=
 f =3D (void(*)())nullptr; =C2=A0// puts f back into the &quot;empty&quot; =
state, definitely ill-advised, you are paying for a null-check here</div><d=
iv><br></div></div><div><div>inplace_function <b><i>does</i></b> assume tha=
t if you&#39;re putting a function-pointer value into it, it&#39;s the valu=
e of a callable:</div><div><a href=3D"https://github.com/WG21-SG14/SG14/blo=
b/master/SG14/inplace_function.h#L182">https://github.com/WG21-SG14/SG14/bl=
ob/master/SG14/inplace_function.h#L182</a><br></div></div><div><br></div><d=
iv>=C2=A0 =C2=A0 inplace_function&lt;void()&gt; f;</div><div>=C2=A0 =C2=A0 =
f =3D nullptr; =C2=A0// puts f back into the &quot;empty&quot; state, argua=
bly ill-advised</div><div>=C2=A0 =C2=A0 f =3D (void(*)())nullptr; =C2=A0// =
makes f &quot;non-empty&quot; but of course will have UB if you accidentall=
y call it</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

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

--001a11478ef68773b4056a63c956--

.

--0000000000006cca16056a8780a9
Content-Type: text/plain; charset="UTF-8"

On Sat, Apr 21, 2018 at 2:08 PM Nicol Bolas <jmckesson@gmail.com> wrote:

> On Friday, April 20, 2018 at 3:00:09 PM UTC-4, Mutz, Marc wrote:
>>
>> On 2018-04-20 19:36, 'Matt Calabrese' via ISO C++ Standard - Future
>> Proposals wrote:
>> [...]
>> > Explicitly
>> > providing throwing and non-throwing versions for each does not seem
>> > ideal.
>>
>> True. Esp. in the light of YAFRM[1] which will prompt the next guy to
>> request
>>
>>    std::expected<R> function<R(Args...)>::operator(Args...args) {
>>       if (bool(*this)) return call(forward<Args>(args)...);
>>       else return unexpected(~~~);
>>    }
>>
>> C++ vocabulary types should implement the hard bits, not meddle with
>> policy. So, std::function should deal with the type erasure of
>> callables, and state non-emptiness as a precondition for calling op().
>> People can then write wrappers that throw exceptions, or return
>> std::expected, as they feel is right for them.
>>
>
> Vocabulary types are supposed to be types that you just take off the shelf
> and use as is. If you have to write wrappers to use them "properly", then
> they're *not* "vocabulary types", are they? That's why having the
> "wrapper" built into the type makes sense.
>

A few thoughts:

1) You don't need to wrap the std::function template -- if you frequently
want to check if it's empty before the call and do something specific in
that case, all you need is a function template that does that.

2) I would be very suspicious of code actually dealing with this exception.
For reasons already mentioned, use of such functionality is generally a)
trying to use an exception for normal control flow, or b) trying to
"recover" from what is more like a contract violation (a bug). I am not
thrilled that the standard library encourages either of these. In some
sense related -- would people want a null std::unique_ptr dereference to
throw? The cases aren't strictly equal, but what sets these two apart? If
you are trying to use certain functionality of either of these when in the
null state, I would argue that it is a *bug* in your code. Both should
simply be precondition violations, yet while that is true for unique_ptr,
it is not for std::function. Why the difference, or is it suggested that
unique_ptr should also have duplicate interfaces that perform the check?

3) No type can be everything to everyone, including what people have lately
been calling "vocabulary types". At the very least, let's not have
different flavors of the same function with just different forms of
checking.

-- Matt Calabrese

--
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/CANh8DEko5XSqWmMq2FM8mo1d7HqkcdrQz5ECxj6fKR9qtaKkcw%40mail.gmail.com.

--0000000000006cca16056a8780a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Apr 21=
, 2018 at 2:08 PM Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jm=
ckesson@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">On Friday, April 20, 2018 at 3:00:09 PM UTC-4, Mutz, Marc wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On 2018-04-20 19:36, &#39;Matt =
Calabrese&#39; via ISO C++ Standard - Future=20
<br>Proposals wrote:
<br>[...]
<br>&gt; Explicitly
<br>&gt; providing throwing and non-throwing versions for each does not see=
m
<br>&gt; ideal.
<br>
<br>True. Esp. in the light of YAFRM[1] which will prompt the next guy to=
=20
<br>request
<br>
<br>=C2=A0 =C2=A0std::expected&lt;R&gt; function&lt;R(Args...)&gt;::operato=
r(Args...args) {
<br>=C2=A0 =C2=A0 =C2=A0 if (bool(*this)) return call(forward&lt;Args&gt;(a=
rgs)...);
<br>=C2=A0 =C2=A0 =C2=A0 else return unexpected(~~~);
<br>=C2=A0 =C2=A0}
<br>
<br>C++ vocabulary types should implement the hard bits, not meddle with=20
<br>policy. So, std::function should deal with the type erasure of=20
<br>callables, and state non-emptiness as a precondition for calling op().=
=20
<br>People can then write wrappers that throw exceptions, or return=20
<br>std::expected, as they feel is right for them.
<br></blockquote><div><br>Vocabulary types are supposed to be types that yo=
u just take off the shelf and use as is. If you have to write wrappers to u=
se them &quot;properly&quot;, then they&#39;re <i>not</i> &quot;vocabulary =
types&quot;, are they? That&#39;s why having the &quot;wrapper&quot; built =
into the type makes sense.</div></div></blockquote><div><br class=3D"gmail-=
Apple-interchange-newline"><span style=3D"color:rgb(34,34,34);font-family:s=
ans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;fo=
nt-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);text-decoration-style:initial;text-decora=
tion-color:initial;float:none;display:inline">A few thoughts:</span></div><=
div><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13p=
x;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;=
font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(25=
5,255,255);text-decoration-style:initial;text-decoration-color:initial;floa=
t:none;display:inline"><br></span></div><div><span style=3D"color:rgb(34,34=
,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-l=
igatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:i=
nitial;text-decoration-color:initial;float:none;display:inline">1) You don&=
#39;t need to wrap the std::function template -- if you frequently want to =
check if it&#39;s empty before the call and do something specific in that c=
ase, all you need is a function template that does that.</span><br></div><d=
iv><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px=
;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;f=
ont-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255=
,255,255);text-decoration-style:initial;text-decoration-color:initial;float=
:none;display:inline"><br></span></div><div><span style=3D"color:rgb(34,34,=
34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-li=
gatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:in=
itial;text-decoration-color:initial;float:none;display:inline">2) I would b=
e very suspicious of code actually dealing with this exception. For reasons=
 already mentioned, use of such functionality is generally a) trying to use=
 an exception for normal control flow, or b) trying to &quot;recover&quot; =
from what is more like a contract violation (a bug). I am not thrilled that=
 the standard library encourages either of these. In some sense related -- =
would people want a null std::unique_ptr dereference to throw? The cases ar=
en&#39;t strictly equal, but what sets these two apart? If you are trying t=
o use certain functionality of either of these when in the null state, I wo=
uld argue that it is a *bug* in your code. Both should simply be preconditi=
on violations, yet while that is true for unique_ptr, it is not for std::fu=
nction. Why the difference, or is it suggested that unique_ptr should also =
have duplicate interfaces that perform the check?</span></div><div><span st=
yle=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style=
:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:=
400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);t=
ext-decoration-style:initial;text-decoration-color:initial;float:none;displ=
ay:inline"><br></span></div><div>3) No type can be everything to everyone, =
including what people have lately been calling &quot;vocabulary types&quot;=
.. At the very least, let&#39;s not have different flavors of the same funct=
ion with just different forms of checking.</div><div><br></div><div>-- Matt=
 Calabrese</div></div></div>

<p></p>

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

--0000000000006cca16056a8780a9--

.

--001a114dcff8e34596056a87b4f7
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 23, 2018 at 12:38 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

>
> 2) I would be very suspicious of code actually dealing with this
> exception. For reasons already mentioned, use of such functionality is
> generally a) trying to use an exception for normal control flow, or b)
> trying to "recover" from what is more like a contract violation (a bug). I
> am not thrilled that the standard library encourages either of these. In
> some sense related -- would people want a null std::unique_ptr dereference
> to throw? The cases aren't strictly equal, but what sets these two apart?
> If you are trying to use certain functionality of either of these when in
> the null state, I would argue that it is a *bug* in your code. Both should
> simply be precondition violations, yet while that is true for unique_ptr,
> it is not for std::function. Why the difference, or is it suggested that
> unique_ptr should also have duplicate interfaces that perform the check?
>

IIRC, the argument for marking unique_ptr dereferencing as noexcept was a
performance one in that we never want to pay the cost of a check for null
pointer values in production code.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BOeQBh0KZ8Xni%2Ba%2BgR955XPe3jKM2q6TGbRHHGp%2BGFnCA%40mail.gmail.com.

--001a114dcff8e34596056a87b4f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Apr 23, 2018 at 12:38 PM, &#39;Matt Calabrese&#39;=
 via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><span class=3D""><div dir=3D"ltr"><br></div></span><div><span style=3D"=
color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal=
;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-dec=
oration-style:initial;text-decoration-color:initial;float:none;display:inli=
ne">2) I would be very suspicious of code actually dealing with this except=
ion. For reasons already mentioned, use of such functionality is generally =
a) trying to use an exception for normal control flow, or b) trying to &quo=
t;recover&quot; from what is more like a contract violation (a bug). I am n=
ot thrilled that the standard library encourages either of these. In some s=
ense related -- would people want a null std::unique_ptr dereference to thr=
ow? The cases aren&#39;t strictly equal, but what sets these two apart? If =
you are trying to use certain functionality of either of these when in the =
null state, I would argue that it is a *bug* in your code. Both should simp=
ly be precondition violations, yet while that is true for unique_ptr, it is=
 not for std::function. Why the difference, or is it suggested that unique_=
ptr should also have duplicate interfaces that perform the check?</span></d=
iv></div></div></blockquote><div><br></div><div>IIRC, the argument for mark=
ing unique_ptr dereferencing as noexcept was a performance one in that we n=
ever want to pay the cost of a check for null pointer values in production =
code.</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gm=
ail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quo=
t;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</d=
iv></div></div></div></div>
</div></div>

<p></p>

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

--001a114dcff8e34596056a87b4f7--

.

On 23 April 2018 at 20:52, Nevin Liber <nevin@eviloverlord.com> wrote:
> IIRC, the argument for marking unique_ptr dereferencing as noexcept was a
> performance one in that we never want to pay the cost of a check for null
> pointer values in production code.

In my case, the reason for wanting that dereference to be noexcept is
that I'd really want to avoid
the result of a noexcept query on *foo or bar->boink() to be always
false. In the latter case, I would
much prefer the result depending on the noexceptness of boink, rather
than being always false.

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

.

--000000000000102dc0056a87f3d9
Content-Type: text/plain; charset="UTF-8"

On Mon, Apr 23, 2018 at 1:52 PM Nevin Liber <nevin@eviloverlord.com> wrote:

> On Mon, Apr 23, 2018 at 12:38 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>>
>> 2) I would be very suspicious of code actually dealing with this
>> exception. For reasons already mentioned, use of such functionality is
>> generally a) trying to use an exception for normal control flow, or b)
>> trying to "recover" from what is more like a contract violation (a bug). I
>> am not thrilled that the standard library encourages either of these. In
>> some sense related -- would people want a null std::unique_ptr dereference
>> to throw? The cases aren't strictly equal, but what sets these two apart?
>> If you are trying to use certain functionality of either of these when in
>> the null state, I would argue that it is a *bug* in your code. Both should
>> simply be precondition violations, yet while that is true for unique_ptr,
>> it is not for std::function. Why the difference, or is it suggested that
>> unique_ptr should also have duplicate interfaces that perform the check?
>>
>
> IIRC, the argument for marking unique_ptr dereferencing as noexcept was a
> performance one in that we never want to pay the cost of a check for null
> pointer values in production code.
>

That doesn't quite tell me why we do not have a throwing form of access *in
addition* to the forms that do not throw. I'm clearly personally against
adding such functionality because I think it would encourage a misuse of
exceptions, but it seems strange that we would point to performance as a
rationale when a user wouldn't be paying for that performance with a
separate accessor (as we've done for other types). For people who want to
check in the cases of unique_ptr, it doesn't seem to have been an excessive
burden on them. Why, then, does it seem to be an excessive burden for
std::function? I've seen both of these types called "vocabulary types", as
much as I dislike that term.

-- Matt Calabrese

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

--000000000000102dc0056a87f3d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 23=
, 2018 at 1:52 PM Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com"=
>nevin@eviloverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Mon, Apr 23, 2018 at 12:38 PM, &#39;Matt Calabrese&=
#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_quote"><span><div dir=3D"ltr"><br></div></span><div><span style=3D"color:=
rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-=
variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-sp=
acing:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoratio=
n-style:initial;text-decoration-color:initial;float:none;display:inline">2)=
 I would be very suspicious of code actually dealing with this exception. F=
or reasons already mentioned, use of such functionality is generally a) try=
ing to use an exception for normal control flow, or b) trying to &quot;reco=
ver&quot; from what is more like a contract violation (a bug). I am not thr=
illed that the standard library encourages either of these. In some sense r=
elated -- would people want a null std::unique_ptr dereference to throw? Th=
e cases aren&#39;t strictly equal, but what sets these two apart? If you ar=
e trying to use certain functionality of either of these when in the null s=
tate, I would argue that it is a *bug* in your code. Both should simply be =
precondition violations, yet while that is true for unique_ptr, it is not f=
or std::function. Why the difference, or is it suggested that unique_ptr sh=
ould also have duplicate interfaces that perform the check?</span></div></d=
iv></div></blockquote><div><br></div><div>IIRC, the argument for marking un=
ique_ptr dereferencing as noexcept was a performance one in that we never w=
ant to pay the cost of a check for null pointer values in production code.<=
/div></div></div></div></blockquote><div><br></div><div>That doesn&#39;t qu=
ite tell me why we do not have a throwing form of access <span style=3D"col=
or:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;fo=
nt-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter=
-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-=
space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decora=
tion-style:initial;text-decoration-color:initial;float:none;display:inline"=
>*in addition* to the forms that do not throw</span>. I&#39;m clearly perso=
nally against adding such functionality because I think it would encourage =
a misuse of exceptions, but it seems strange that we would point to perform=
ance as a rationale when a user wouldn&#39;t be paying for that performance=
 with a separate accessor (as we&#39;ve done for other types). For people w=
ho want to check in the cases of unique_ptr, it doesn&#39;t seem to have be=
en an excessive burden on them. Why, then, does it seem to be an excessive =
burden for std::function? I&#39;ve seen both of these types called &quot;vo=
cabulary types&quot;, as much as I dislike that term.</div><div><br></div><=
div>-- Matt Calabrese</div></div></div>

<p></p>

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

--000000000000102dc0056a87f3d9--

.

------=_Part_15508_1710224776.1524561992911
Content-Type: multipart/alternative;
 boundary="----=_Part_15509_597001086.1524561992911"

------=_Part_15509_597001086.1524561992911
Content-Type: text/plain; charset="UTF-8"

My position on this point is that user should have a choice to use "safe"
or "unsafe" interface and the "unsafe" interface must be uglier. E.g.
interface of my pre-C++17 variant:

template<class... T>
class variant
{
public:
    template<unsigned I>
    option_type<I> &get_unchecked();

    template<unsigned I>
    option_type<I> &get()
    {
        if(I != index()) throw invalid_variant_access{};
        return get_unchecked<I>();
    }
};

So why can't just add

f.call_unchecked(...)
or
f.call_unsafe(...)

?

--
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/74905a33-d14d-428d-9ea2-2eaf2767d963%40isocpp.org.

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

<div dir=3D"ltr">My position on this point is that user should have a choic=
e to use &quot;safe&quot; or &quot;unsafe&quot; interface and the &quot;uns=
afe&quot; interface must be uglier. E.g. interface of my pre-C++17 variant:=
<br><br><span style=3D"font-family: courier\ new, monospace;">template&lt;c=
lass... T&gt;<br>class variant<br>{<br>public:<br>=C2=A0=C2=A0=C2=A0 templa=
te&lt;unsigned I&gt;<br>=C2=A0 =C2=A0 option_type&lt;I&gt; &amp;get_uncheck=
ed();<br><br>=C2=A0=C2=A0=C2=A0 template&lt;unsigned I&gt;<br>=C2=A0 =C2=A0=
 option_type&lt;I&gt; &amp;get()<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 if(I !=3D index()) throw invalid_variant_access=
{};<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return get_unchecked&lt;I=
&gt;();<br>=C2=A0=C2=A0=C2=A0 }<br>};<br></span><br>So why can&#39;t just a=
dd <br><br>f.call_unchecked(...)<br>or<br>f.call_unsafe(...)<br><br>?<br></=
div>

<p></p>

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

------=_Part_15509_597001086.1524561992911--

------=_Part_15508_1710224776.1524561992911--

.

------=_Part_15998_1227221904.1524562169811
Content-Type: multipart/alternative;
 boundary="----=_Part_15999_587663989.1524562169811"

------=_Part_15999_587663989.1524562169811
Content-Type: text/plain; charset="UTF-8"

And we have such thing for std::optional: operator*() vs value(). It's
good, in spite of the difference between calls is not so obvious and
self-documented.

--
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/5a547d3a-6805-4a7d-90cc-048f8b5b0a2d%40isocpp.org.

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

<div dir=3D"ltr">And we have such thing for std::optional: operator*() vs v=
alue(). It&#39;s good, in spite of the difference between calls is not so o=
bvious and self-documented.<br></div>

<p></p>

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

------=_Part_15999_587663989.1524562169811--

------=_Part_15998_1227221904.1524562169811--

.

> On 18 Apr 2018, at 10:33, Mutz, Marc <marc@kdab.com> wrote:
>=20
> Hi,
>=20
> Is there any way to "fix" std::function's function call operator to not t=
hrow on empty, but make it UB? It expands to quite some more code than shou=
ld be necessary to call a std::function, even if your own code's preconditi=
on is that the object is not empty. This is in violation of DPFWYDN (don't =
pay for what you don't use), because there's no way to call the function wi=
thout the check.

IMHO there is way too much obsession in these channels about the =E2=80=9Cc=
ost=E2=80=9D of exceptions.

FACT: Exceptions cost no more than return-code checking when on the non-exc=
eptional path.

At this point, the usual tactic is to bring up embedded system performance.=
=20

FACT: The single most-used embedded language is Java, the language of mobil=
e phone SIM cards. Apparently, even in these extremely low-powered environm=
ents, there is no problem whatsoever with exceptions being in the language.

No other language=E2=80=99s users whinge and moan about the exceptions that=
 are a fully integral part of their language.

Honestly=E2=80=A6 I love you guys, but you (we) need to focus on making c++=
 more useable, not more niche.=20

Look at the big picture.

Do companies choose to do new development in Java and C# because c++ has na=
sty exceptions?=20

No. They use these languages because easy access to functional libraries ma=
kes it a no-brainer.



>=20
> Consider, otoh, std::vector::operator[] vs. std::vector::at(). The first =
called with an index out of range is UB while the second has defined behavi=
our: an exception is thrown. Here, the user can choose whether to pay the p=
rice for checking or not. With std::function, there's no way to forego the =
check - at least portably. GCC can be persuaded to drop all checks when the=
 function call is preceded by if (!f) __builtin_unreachable(). Clang ignore=
s this:
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 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/isoc=
pp.org/d/msgid/std-proposals/6e84f31f1801bcc16a054279eede5e02%40kdab.com.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/B418598E-17D7-4B1C-895E-D5A700390B79%40gmail.com=
..

.

On April 24, 2018 12:26:34 PM Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

My position on this point is that user should have a choice to use "safe"
or "unsafe" interface and the "unsafe" interface must be uglier.

Why must it be uglier?

IMHO, the "safety" argument is an illusion, unless you actually want that
exception in one of your use cases, which I find hard to believe. I mean,
you'd have to intentionally allow the std::function to be empty and catch
the exception somewhere up the stack. In this case, why not explicitly test
the function for being empty and avoid the cost of throwing an exception?

Note that this is not a protection against an unintended call. By
definition, such call would be unexpected and the surrounding code will
likely be unprepared for the exception.



--
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/162f72d1a58.2731.fb49792bc380c7e55e30f872b414f11c%40gmail.com.

.

--0000000000007e27f6056a966bd9
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 06:23 Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> IMHO, the "safety" argument is an illusion, unless you actually want that
> exception in one of your use cases, which I find hard to believe. I mean,
> you'd have to intentionally allow the std::function to be empty and catch
> the exception somewhere up the stack. In this case, why not explicitly
> test
> the function for being empty and avoid the cost of throwing an exception?
>
> Note that this is not a protection against an unintended call. By
> definition, such call would be unexpected and the surrounding code will
> likely be unprepared for the exception.
>

+1

This is exactly my point. The belief that an exception here is "safe" is
totally misguided. An exception is not a "safe" thing to do when you
discover a bug, nor is it a proper way to simply branch. These are both
misuses of exceptions that we should not be encouraging in the standard.
It's clear that some developers throw in places like this, but it is a
mistake. The "safe" thing to do is to have a solid contract.




>

--
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/CANh8DEmsfmP4v9tMR3K5N%2BAa8wThp0i3QgNN%2BZK3j0%2BxxBt1pQ%40mail.gmail.com.

--0000000000007e27f6056a966bd9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
Apr 24, 2018, 06:23 Andrey Semashev &lt;<a href=3D"mailto:andrey.semashev@g=
mail.com" target=3D"_blank" rel=3D"noreferrer">andrey.semashev@gmail.com</a=
>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
IMHO, the &quot;safety&quot; argument is an illusion, unless you actually w=
ant that <br>
exception in one of your use cases, which I find hard to believe. I mean, <=
br>
you&#39;d have to intentionally allow the std::function to be empty and cat=
ch <br>
the exception somewhere up the stack. In this case, why not explicitly test=
 <br>
the function for being empty and avoid the cost of throwing an exception?<b=
r>
<br>
Note that this is not a protection against an unintended call. By <br>
definition, such call would be unexpected and the surrounding code will <br=
>
likely be unprepared for the exception.<br></blockquote></div></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">+1</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">This is exactly my point. The belief that an exception he=
re is &quot;safe&quot; is totally misguided. An exception is not a &quot;sa=
fe&quot; thing to do when you discover a bug, nor is it a proper way to sim=
ply branch. These are both misuses of exceptions that we should not be enco=
uraging in the standard. It&#39;s clear that some developers throw in place=
s like this, but it is a mistake. The &quot;safe&quot; thing to do is to ha=
ve a solid contract.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div></div></div>

<p></p>

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

--0000000000007e27f6056a966bd9--

.

------=_Part_28959_1806243571.1524569723338
Content-Type: multipart/alternative;
 boundary="----=_Part_28960_1871546980.1524569723338"

------=_Part_28960_1871546980.1524569723338
Content-Type: text/plain; charset="UTF-8"



On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andrey Semashev wrote:
>
> Why must it be uglier?
>
To be friendlier to juniors and other non-experts. C++ can be used not only
by programmers but by other people who just need to use comuter.


> IMHO, the "safety" argument is an illusion, unless you actually want that
> exception in one of your use cases, which I find hard to believe.
>
By "safety"  I mean "fail-fast". All we can misunderstand the code.
Exception is usually much more better than subsequent segfault in other
piece of code. And even more better than silent data corruption.

--
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/29d9fa98-c7d5-4d64-b95b-c44f6cdc8c24%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, An=
drey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Why must it be uglier?
<br></blockquote><div>To be friendlier to juniors and other non-experts. C+=
+ can be used not only by programmers but by other people who just need to =
use comuter.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">IM=
HO, the &quot;safety&quot; argument is an illusion, unless you actually wan=
t that=20
<br>exception in one of your use cases, which I find hard to believe.<br></=
blockquote><div>By &quot;safety&quot;=C2=A0 I mean &quot;fail-fast&quot;. A=
ll we can misunderstand the code. Exception is usually much more better tha=
n subsequent segfault in other piece of code. And even more better than sil=
ent data corruption.<br></div></div>

<p></p>

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

------=_Part_28960_1871546980.1524569723338--

------=_Part_28959_1806243571.1524569723338--

.

------=_Part_29223_1427273110.1524569955540
Content-Type: multipart/alternative;
 boundary="----=_Part_29224_1304426969.1524569955540"

------=_Part_29224_1304426969.1524569955540
Content-Type: text/plain; charset="UTF-8"

more better = better

Sorry my english

--
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/48f4ac82-6b7c-4aae-87a0-a32cf458e1a2%40isocpp.org.

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

<div dir=3D"ltr">more better =3D better<br><br>Sorry my english<br></div>

<p></p>

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

------=_Part_29224_1304426969.1524569955540--

------=_Part_29223_1427273110.1524569955540--

.

--000000000000e6b6d9056a96a217
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 07:35 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andrey Semashev wrote:
>>
>> Why must it be uglier?
>>
> To be friendlier to juniors and other non-experts. C++ can be used not
> only by programmers but by other people who just need to use comuter.
>

Throwing an exception on a bug is not "failing fast". An assert triggering
is an example of "failing fast". By explicitly defining that an exception
is thrown, you are forcing the implementations to not fail fast and are
telling users that this is a mistake they may recover from.

--
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/CANh8DE%3D354omrGsY0qUM%3Dm%2BMWu3h%2B0c-WxyxRJwiV5eMPc07mg%40mail.gmail.com.

--000000000000e6b6d9056a96a217
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, Apr 24, 2018, 07:35 Victor Dyachenko &lt;<a href=3D"mailto:victor.d=
yachenko@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 1:23:=
06 PM UTC+3, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Why must it be uglier?
<br></blockquote><div>To be friendlier to juniors and other non-experts. C+=
+ can be used not only by programmers but by other people who just need to =
use comuter.<br></div></div></blockquote></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Throwing an exception on a bug is not &quot;failing=
 fast&quot;. An assert triggering is an example of &quot;failing fast&quot;=
.. By explicitly defining that an exception is thrown, you are forcing the i=
mplementations to not fail fast and are telling users that this is a mistak=
e they may recover from.</div></div>

<p></p>

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

--000000000000e6b6d9056a96a217--

.

------=_Part_28483_1166619315.1524570527585
Content-Type: multipart/alternative;
 boundary="----=_Part_28484_1916957477.1524570527586"

------=_Part_28484_1916957477.1524570527586
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 2:41:37 PM UTC+3, Matt Calabrese wrote:
>
>
>
> On Tue, Apr 24, 2018, 07:35 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andrey Semashev wrote:
>>>
>>> Why must it be uglier?
>>>
>> To be friendlier to juniors and other non-experts. C++ can be used not
>> only by programmers but by other people who just need to use comuter.
>>
>
> Throwing an exception on a bug is not "failing fast". An assert triggering
> is an example of "failing fast". By explicitly defining that an exception
> is thrown, you are forcing the implementations to not fail fast and are
> telling users that this is a mistake they may recover from.
>

Exceptions are bug in C++ language design? All throw expressions must be
replaced by assert()/abort()? Is it what you want to state eventually? I
really don't understand your point here...

--
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/207ac9cc-3e0e-47e3-9176-b6834bb753f2%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 2:41:37 PM UTC+3, Matt Calab=
rese 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"auto"><=
div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 24, 201=
8, 07:35 Victor Dyachenko &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"JCJPZh3vAwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">victor.d...@gmail.com</a>&gt; wrote:</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 1:23:=
06 PM UTC+3, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Why must it be uglier?
<br></blockquote><div>To be friendlier to juniors and other non-experts. C+=
+ can be used not only by programmers but by other people who just need to =
use comuter.<br></div></div></blockquote></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Throwing an exception on a bug is not &quot;failing=
 fast&quot;. An assert triggering is an example of &quot;failing fast&quot;=
.. By explicitly defining that an exception is thrown, you are forcing the i=
mplementations to not fail fast and are telling users that this is a mistak=
e they may recover from.</div></div></blockquote><div><br>Exceptions are bu=
g in C++ language design? All throw expressions must be replaced by assert(=
)/abort()? Is it what you want to state eventually? I really don&#39;t unde=
rstand your point here...<br></div></div>

<p></p>

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

------=_Part_28484_1916957477.1524570527586--

------=_Part_28483_1166619315.1524570527585--

.

--00000000000090adc2056a96d867
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 07:48 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> On Tuesday, April 24, 2018 at 2:41:37 PM UTC+3, Matt Calabrese wrote:
>>
>>
>>
>> On Tue, Apr 24, 2018, 07:35 Victor Dyachenko <victor.d...@gmail.com>
>> wrote:
>>
>>> On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andrey Semashev wrote:
>>>>
>>>> Why must it be uglier?
>>>>
>>> To be friendlier to juniors and other non-experts. C++ can be used not
>>> only by programmers but by other people who just need to use comuter.
>>>
>>
>> Throwing an exception on a bug is not "failing fast". An assert
>> triggering is an example of "failing fast". By explicitly defining that an
>> exception is thrown, you are forcing the implementations to not fail fast
>> and are telling users that this is a mistake they may recover from.
>>
>
> Exceptions are bug in C++ language design? All throw expressions must be
> replaced by assert()/abort()? Is it what you want to state eventually? I
> really don't understand your point here...
>

No. You should not use exceptions for alerting the user of a *bug* in their
code. An example of a solid use of an exception is to communicate when a
function simply cannot reach its postcondition but where the caller did not
violate a contract.

>

--
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/CANh8DEkNjYBoAnqWBtZYj_%2BXsM%2Bh3irQ-MnnXMy--r9NiUC0_g%40mail.gmail.com.

--00000000000090adc2056a96d867
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, Apr 24, 2018, 07:48 Victor Dyachenko &lt;<a href=3D"mailto:victor.d=
yachenko@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 2=
:41:37 PM UTC+3, Matt Calabrese 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"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Tue, Apr 24, 2018, 07:35 Victor Dyachenko &lt;<a rel=3D"nofollow nore=
ferrer">victor.d...@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andr=
ey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Why must it be uglier?
<br></blockquote><div>To be friendlier to juniors and other non-experts. C+=
+ can be used not only by programmers but by other people who just need to =
use comuter.<br></div></div></blockquote></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Throwing an exception on a bug is not &quot;failing=
 fast&quot;. An assert triggering is an example of &quot;failing fast&quot;=
.. By explicitly defining that an exception is thrown, you are forcing the i=
mplementations to not fail fast and are telling users that this is a mistak=
e they may recover from.</div></div></blockquote><div><br>Exceptions are bu=
g in C++ language design? All throw expressions must be replaced by assert(=
)/abort()? Is it what you want to state eventually? I really don&#39;t unde=
rstand your point here...</div></div></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">No. You should not use exceptions for aler=
ting the user of a *bug* in their code. An example of a solid use of an exc=
eption is to communicate when a function simply cannot reach its postcondit=
ion but where the caller did not violate a contract.</div><div dir=3D"auto"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

<p></p>

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

--00000000000090adc2056a96d867--

.

--000000000000b925e1056a96ddf4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 24, 2018 at 10:47 AM, Richard Hodges <hodges.r@gmail.com> wrote=
:

>
>
> > On 18 Apr 2018, at 10:33, Mutz, Marc <marc@kdab.com> wrote:
> >
> > Hi,
> >
> > Is there any way to "fix" std::function's function call operator to not
> throw on empty, but make it UB? It expands to quite some more code than
> should be necessary to call a std::function, even if your own code's
> precondition is that the object is not empty. This is in violation of
> DPFWYDN (don't pay for what you don't use), because there's no way to cal=
l
> the function without the check.
>
> IMHO there is way too much obsession in these channels about the =E2=80=
=9Ccost=E2=80=9D of
> exceptions.
>
> FACT: Exceptions cost no more than return-code checking when on the
> non-exceptional path.
>
> At this point, the usual tactic is to bring up embedded system
> performance.
>
> FACT: The single most-used embedded language is Java, the language of
> mobile phone SIM cards. Apparently, even in these extremely low-powered
> environments, there is no problem whatsoever with exceptions being in the
> language.
>
> No other language=E2=80=99s users whinge and moan about the exceptions th=
at are a
> fully integral part of their language.
>
> Honestly=E2=80=A6 I love you guys, but you (we) need to focus on making c=
++ more
> useable, not more niche.
>
> Look at the big picture.
>
> Do companies choose to do new development in Java and C# because c++ has
> nasty exceptions?
>
> No. They use these languages because easy access to functional libraries
> makes it a no-brainer.
>
>
This is a pretty good argument for putting C++ to sleep in general, if
true.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFQaeCCaLS8quDG5LvtjDQv5rrP_uWanbLdFWSN1qdTsb3x=
Phw%40mail.gmail.com.

--000000000000b925e1056a96ddf4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Apr 24, 2018 at 10:47 AM, Richard Hodges <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:hodges.r@gmail.com" target=3D"_blank">hodges.r@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
&gt; On 18 Apr 2018, at 10:33, Mutz, Marc &lt;<a href=3D"mailto:marc@kdab.c=
om">marc@kdab.com</a>&gt; wrote:<br>
&gt; <br>
&gt; Hi,<br>
&gt; <br>
&gt; Is there any way to &quot;fix&quot; std::function&#39;s function call =
operator to not throw on empty, but make it UB? It expands to quite some mo=
re code than should be necessary to call a std::function, even if your own =
code&#39;s precondition is that the object is not empty. This is in violati=
on of DPFWYDN (don&#39;t pay for what you don&#39;t use), because there&#39=
;s no way to call the function without the check.<br>
<br>
</span>IMHO there is way too much obsession in these channels about the =E2=
=80=9Ccost=E2=80=9D of exceptions.<br>
<br>
FACT: Exceptions cost no more than return-code checking when on the non-exc=
eptional path.<br>
<br>
At this point, the usual tactic is to bring up embedded system performance.=
 <br>
<br>
FACT: The single most-used embedded language is Java, the language of mobil=
e phone SIM cards. Apparently, even in these extremely low-powered environm=
ents, there is no problem whatsoever with exceptions being in the language.=
<br>
<br>
No other language=E2=80=99s users whinge and moan about the exceptions that=
 are a fully integral part of their language.<br>
<br>
Honestly=E2=80=A6 I love you guys, but you (we) need to focus on making c++=
 more useable, not more niche. <br>
<br>
Look at the big picture.<br>
<br>
Do companies choose to do new development in Java and C# because c++ has na=
sty exceptions? <br>
<br>
No. They use these languages because easy access to functional libraries ma=
kes it a no-brainer.<br><br></blockquote><div><br></div><div>This is a pret=
ty good argument for putting C++ to sleep in general, if true.=C2=A0</div><=
/div><br></div></div>

<p></p>

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

--000000000000b925e1056a96ddf4--

.

------=_Part_29046_1289162608.1524571463765
Content-Type: multipart/alternative;
 boundary="----=_Part_29047_1108135233.1524571463765"

------=_Part_29047_1108135233.1524571463765
Content-Type: text/plain; charset="UTF-8"



On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Matt Calabrese wrote:
>
>
>
> On Tue, Apr 24, 2018, 07:48 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, April 24, 2018 at 2:41:37 PM UTC+3, Matt Calabrese wrote:
>>>
>>>
>>>
>>> On Tue, Apr 24, 2018, 07:35 Victor Dyachenko <victor.d...@gmail.com>
>>> wrote:
>>>
>>>> On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andrey Semashev wrote:
>>>>>
>>>>> Why must it be uglier?
>>>>>
>>>> To be friendlier to juniors and other non-experts. C++ can be used not
>>>> only by programmers but by other people who just need to use comuter.
>>>>
>>>
>>> Throwing an exception on a bug is not "failing fast". An assert
>>> triggering is an example of "failing fast". By explicitly defining that an
>>> exception is thrown, you are forcing the implementations to not fail fast
>>> and are telling users that this is a mistake they may recover from.
>>>
>>
>> Exceptions are bug in C++ language design? All throw expressions must be
>> replaced by assert()/abort()? Is it what you want to state eventually? I
>> really don't understand your point here...
>>
>
> No. You should not use exceptions for alerting the user of a *bug* in
> their code. An example of a solid use of an exception is to communicate
> when a function simply cannot reach its postcondition but where the caller
> did not violate a contract.
>

"Bug" is a really high-level concept. Exception is not a bug if handled
thoroughly. E.g. is bad_alloc is bug in implemetation? Or is it fatal
error? No if you have "plan B" - an alternative algorithm that is slower
but can be done with less memory.

--
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/d6fae4c1-0dda-4c83-9fb6-2f92718498a1%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Ma=
tt Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr=
 24, 2018, 07:48 Victor Dyachenko &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"inqEyO7vAwAJ" rel=3D"nofollow" onmousedown=3D=
"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#3=
9;javascript:&#39;;return true;">victor.d...@gmail.com</a>&gt; 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">On Tuesday, April 24, 2=
018 at 2:41:37 PM UTC+3, Matt Calabrese wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Tue, Apr 24, 2018, 07:35 Victor Dyachenko &lt;<a rel=3D"nofol=
low noreferrer">victor.d...@gmail.com</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 1:23:06 PM UTC=
+3, Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Why must it be uglier?
<br></blockquote><div>To be friendlier to juniors and other non-experts. C+=
+ can be used not only by programmers but by other people who just need to =
use comuter.<br></div></div></blockquote></div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Throwing an exception on a bug is not &quot;failing=
 fast&quot;. An assert triggering is an example of &quot;failing fast&quot;=
.. By explicitly defining that an exception is thrown, you are forcing the i=
mplementations to not fail fast and are telling users that this is a mistak=
e they may recover from.</div></div></blockquote><div><br>Exceptions are bu=
g in C++ language design? All throw expressions must be replaced by assert(=
)/abort()? Is it what you want to state eventually? I really don&#39;t unde=
rstand your point here...</div></div></blockquote></div></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">No. You should not use exceptions for aler=
ting the user of a *bug* in their code. An example of a solid use of an exc=
eption is to communicate when a function simply cannot reach its postcondit=
ion but where the caller did not violate a contract.</div></div></blockquot=
e><div><br>&quot;Bug&quot; is a really high-level concept. Exception is not=
 a bug if handled thoroughly. E.g. is bad_alloc is bug in implemetation? Or=
 is it fatal error? No if you have &quot;plan B&quot; - an alternative algo=
rithm that is slower but can be done with less memory.<br></div></div>

<p></p>

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

------=_Part_29047_1108135233.1524571463765--

------=_Part_29046_1289162608.1524571463765--

.

------=_Part_28888_33652292.1524572210895
Content-Type: multipart/alternative;
 boundary="----=_Part_28889_80222946.1524572210895"

------=_Part_28889_80222946.1524572210895
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Matt Calabrese wrote:
>
>
> An example of a solid use of an exception is to communicate when a
> function simply cannot reach its postcondition but where the caller did not
> violate a contract.
>

So it's perfectly OK to throw in the case of std::function. It can't reach
it's postcondition (call the wrapped function) because no function has been
given. And exception is fully defined behavior in contrast to access to
uninitialized memory.

Contract is defined by class/function writer:

std::vector::operator[i] - Precondition: i < size(). UB if violated.
std::vector::at(i) - No precondition. No UB on any i

--
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/d3ba53f5-8867-49f2-8157-51a0f5dba50c%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Matt Calab=
rese 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"auto"><=
br><div dir=3D"auto">An example of a solid use of an exception is to commun=
icate when a function simply cannot reach its postcondition but where the c=
aller did not violate a contract.</div></div></blockquote><div><br>So it&#3=
9;s perfectly OK to throw in the case of std::function. It can&#39;t reach =
it&#39;s postcondition (call the wrapped function) because no function has =
been given. And exception is fully defined behavior in contrast to access t=
o uninitialized memory.<br><br>Contract is defined by class/function writer=
:<br><br>std::vector::operator[i] - Precondition: i &lt; size(). UB if viol=
ated.<br>std::vector::at(i) - No precondition. No UB on any i<br></div></di=
v>

<p></p>

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

------=_Part_28889_80222946.1524572210895--

------=_Part_28888_33652292.1524572210895--

.

--00000000000064101a056a974ab2
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> "Bug" is a really high-level concept. Exception is not a bug if handled
> thoroughly.
>

I've never said that an exception is a bug.

On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> E.g. is bad_alloc is bug in implemetation? Or is it fatal error? No if you
> have "plan B" - an alternative algorithm that is slower but can be done
> with less memory.
>

I never said, nor would I say, that bad_alloc is a bug.

--
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/CANh8DEmwHNetg%3DBjBwMtseonWyAqXBe2v1DL83%3D%2BJ9KoRq6O5Q%40mail.gmail.com.

--00000000000064101a056a974ab2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
Apr 24, 2018, 08:04 Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko=
@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>&quot;Bug&quot; is a really high-level=
 concept. Exception is not a bug if handled thoroughly.</div></div></blockq=
uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve nev=
er said that an exception is a bug.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><span style=3D"font-family:sans-serif">On Tue, Apr 24, 2018, 08=
:04 Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko@gmail.com">vict=
or.dyachenko@gmail.com</a>&gt; wrote:</span><br></div><div dir=3D"auto"><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v>E.g. is bad_alloc is bug in implemetation? Or is it fatal error? No if yo=
u have &quot;plan B&quot; - an alternative algorithm that is slower but can=
 be done with less memory.<br></div></div></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I never said, nor would I say, that b=
ad_alloc is a bug.<br></div></div>

<p></p>

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

--00000000000064101a056a974ab2--

.

------=_Part_16616_1783786065.1524573395058
Content-Type: multipart/alternative;
 boundary="----=_Part_16617_1344840764.1524573395058"

------=_Part_16617_1344840764.1524573395058
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 3:28:27 PM UTC+3, Matt Calabrese wrote:
>
> On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> "Bug" is a really high-level concept. Exception is not a bug if handled
>> thoroughly.
>>
>
> I've never said that an exception is a bug.
>
> On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> E.g. is bad_alloc is bug in implemetation? Or is it fatal error? No if
>> you have "plan B" - an alternative algorithm that is slower but can be done
>> with less memory.
>>
>
> I never said, nor would I say, that bad_alloc is a bug.
>

So what is the difference with std::bad_function_call case? The point is
that in std::function::operator() you really don't know if it is bug for
user or it will be handled well. It's the whole point of exceptions -
transmit the failure on the higher level and get the user to make decision.
When you use assert/abort you don't give such option.

--
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/80c7c706-2a0d-4f8c-9517-9c65e1b978a1%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 3:28:27 PM UTC+3, Matt Calab=
rese 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"auto"><=
div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 24, 2018, 08:04=
 Victor Dyachenko &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"EpnjkavxAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">victor.d...@gmail.com</a>&gt; wrote:</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>&quot;Bug&quot; is a really high-level=
 concept. Exception is not a bug if handled thoroughly.</div></div></blockq=
uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve nev=
er said that an exception is a bug.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto"><span style=3D"font-family:sans-serif">On Tue, Apr 24, 2018, 08=
:04 Victor Dyachenko &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"EpnjkavxAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">victor.d...@gmail.com</a>&gt; wrote:</span><br></div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>E.g. is bad_alloc is bug in implemetation? Or is it fa=
tal error? No if you have &quot;plan B&quot; - an alternative algorithm tha=
t is slower but can be done with less memory.<br></div></div></blockquote><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I never said, nor =
would I say, that bad_alloc is a bug.<br></div></div></blockquote><div><br>=
So what is the difference with std::bad_function_call case? The point is th=
at in std::function::operator() you really don&#39;t know if it is bug for =
user or it will be handled well. It&#39;s the whole point of exceptions - t=
ransmit the failure on the higher level and get the user to make decision. =
When you use assert/abort you don&#39;t give such option.<br></div></div>

<p></p>

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

------=_Part_16617_1344840764.1524573395058--

------=_Part_16616_1783786065.1524573395058--

.

--000000000000a296f9056a9796d9
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 08:16 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Matt Calabrese wrote:
>>
>>
>> An example of a solid use of an exception is to communicate when a
>> function simply cannot reach its postcondition but where the caller did not
>> violate a contract.
>>
>
> So it's perfectly OK to throw in the case of std::function. It can't reach
> it's postcondition (call the wrapped function) because no function has been
> given. And exception is fully defined behavior in contrast to access to
> uninitialized memory.
>

This is why I said we should focus the discussion on whether we should make
contracts narrow or wide rather than on whether we should have "UB" or
"exceptions". Talking about the latter only hides the underlying issue, and
if we get Contracts as a language feature, you could pick your poison
without needing duplicate forms of the same function. I'd never encourage
throwing on precondition violations, but you can go right ahead and do so
if you wanted to. The more important thing we need to establish, in my
opinion, are proper guidelines on when and why a contract should be made
wide rather than narrow, and ideally default to narrow if no rationale for
widening is given. We can easily widen a contract in the future but we
cannot easily narrow. A wide contract also adds more complexity.

In the case of std::function, what are your expected uses for this contract
being wide where the user doesn't simply have a bug in their code?
Similarly, answer the same question but for accessing the target of null a
unique_ptr. In what realistic cases are either of these *not* a developer's
error?

Separately, while I'm not personally a fan of vector::at (you will notably
find that view is not at all uncommon in the committee and also outside of
the committee), but at least for "at" one can make an argument that the
index may be coming more directly from user input and can at least
"recover" by getting different input. Even there I'd argue against it and
the user should simply check rather than using an exception for basic
control flow, but it's at least more defensible than throwing on the
invocation of an empty std::function. In what scenario is the invocation of
a std::function anything other than a developer's bug?

--
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/CANh8DEk55Dy39HqbGzhqgZ2oB45gSQ8i7YMUbcxcuvLsBOq0Yw%40mail.gmail.com.

--000000000000a296f9056a9796d9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
On Tue, Apr 24, 2018, 08:16 Victor Dyachenko &lt;<a href=3D"mailto:victor.d=
yachenko@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 2=
:56:36 PM UTC+3, Matt Calabrese 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"auto"><br><div dir=3D"auto">An example of a solid use of an =
exception is to communicate when a function simply cannot reach its postcon=
dition but where the caller did not violate a contract.</div></div></blockq=
uote><div><br>So it&#39;s perfectly OK to throw in the case of std::functio=
n. It can&#39;t reach it&#39;s postcondition (call the wrapped function) be=
cause no function has been given. And exception is fully defined behavior i=
n contrast to access to uninitialized memory.<br></div></div></blockquote><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is why I said=
 we should focus the discussion on whether we should make contracts narrow =
or wide rather than on whether we should have &quot;UB&quot; or &quot;excep=
tions&quot;. Talking about the latter only hides the underlying issue, and =
if we get Contracts as a language feature, you could pick your poison witho=
ut needing duplicate forms of the same function. I&#39;d never encourage th=
rowing on precondition violations, but you can go right ahead and do so if =
you wanted to. The more important thing we need to establish, in my opinion=
, are proper guidelines on when and why a contract should be made wide rath=
er than narrow, and ideally default to narrow if no rationale for widening =
is given. We can easily widen a contract in the future but we cannot easily=
 narrow. A wide contract also adds more complexity.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">In the case of std::function, what are your exp=
ected uses for this contract being wide where the user doesn&#39;t simply h=
ave a bug in their code? Similarly, answer the same question but for access=
ing the target of null a unique_ptr. In what realistic cases are either of =
these *not* a developer&#39;s error?</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Separately, while I&#39;m not personally a fan of vector::at (=
you will notably find that view is not at all uncommon in the committee and=
 also outside of the committee), but at least for &quot;at&quot; one can ma=
ke an argument that the index may be coming more directly from user input a=
nd can at least &quot;recover&quot; by getting different input. Even there =
I&#39;d argue against it and the user should simply check rather than using=
 an exception for basic control flow, but it&#39;s at least more defensible=
 than throwing on the invocation of an empty std::function. In what scenari=
o is the invocation of a std::function anything other than a developer&#39;=
s bug?</div></div>

<p></p>

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

--000000000000a296f9056a9796d9--

.

--000000000000b60896056a97a09f
Content-Type: text/plain; charset="UTF-8"

On 24 April 2018 at 14:49, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

>
>
> On Tue, Apr 24, 2018, 08:16 Victor Dyachenko <victor.dyachenko@gmail.com>
> wrote:
>
>> On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Matt Calabrese wrote:
>>>
>>>
>>> An example of a solid use of an exception is to communicate when a
>>> function simply cannot reach its postcondition but where the caller did not
>>> violate a contract.
>>>
>>
>> So it's perfectly OK to throw in the case of std::function. It can't
>> reach it's postcondition (call the wrapped function) because no function
>> has been given. And exception is fully defined behavior in contrast to
>> access to uninitialized memory.
>>
>
> This is why I said we should focus the discussion on whether we should
> make contracts narrow or wide rather than on whether we should have "UB" or
> "exceptions". Talking about the latter only hides the underlying issue, and
> if we get Contracts as a language feature, you could pick your poison
> without needing duplicate forms of the same function. I'd never encourage
> throwing on precondition violations, but you can go right ahead and do so
> if you wanted to. The more important thing we need to establish, in my
> opinion, are proper guidelines on when and why a contract should be made
> wide rather than narrow, and ideally default to narrow if no rationale for
> widening is given. We can easily widen a contract in the future but we
> cannot easily narrow. A wide contract also adds more complexity.
>
> In the case of std::function, what are your expected uses for this
> contract being wide where the user doesn't simply have a bug in their code?
> Similarly, answer the same question but for accessing the target of null a
> unique_ptr. In what realistic cases are either of these *not* a developer's
> error?
>
> Separately, while I'm not personally a fan of vector::at (you will notably
> find that view is not at all uncommon in the committee and also outside of
> the committee), but at least for "at" one can make an argument that the
> index may be coming more directly from user input and can at least
> "recover" by getting different input. Even there I'd argue against it and
> the user should simply check rather than using an exception for basic
> control flow, but it's at least more defensible than throwing on the
> invocation of an empty std::function.
>



> In what scenario is the invocation of a std::function anything other than
> a developer's bug?
>

When the target function address injected into the std::function has been
loaded from a shared library, which turned out not to support it, for
starters.



> --
> 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/CANh8DEk55Dy39HqbGzhqgZ2oB45gS
> Q8i7YMUbcxcuvLsBOq0Yw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk55Dy39HqbGzhqgZ2oB45gSQ8i7YMUbcxcuvLsBOq0Yw%40mail.gmail.com?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/CALvx3hYVGU_NaRyLQoJCBUNNip2OxaRPACtgLqh1BQvYVc60gA%40mail.gmail.com.

--000000000000b60896056a97a09f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 24 April 2018 at 14:49, &#39;Matt Calabrese&#39; via ISO C++ Standar=
d - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@=
isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><br><br><div cla=
ss=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Tue, Apr 24, 2018, =
08:16 Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko@gmail.com" ta=
rget=3D"_blank">victor.dyachenko@gmail.com</a>&gt; wrote:<br></div></span><=
span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday,=
 April 24, 2018 at 2:56:36 PM UTC+3, Matt Calabrese wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"auto"><br><div dir=3D"auto">An example o=
f a solid use of an exception is to communicate when a function simply cann=
ot reach its postcondition but where the caller did not violate a contract.=
</div></div></blockquote><div><br>So it&#39;s perfectly OK to throw in the =
case of std::function. It can&#39;t reach it&#39;s postcondition (call the =
wrapped function) because no function has been given. And exception is full=
y defined behavior in contrast to access to uninitialized memory.<br></div>=
</div></blockquote></span></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This is why I said we should focus the discussion on whether we s=
hould make contracts narrow or wide rather than on whether we should have &=
quot;UB&quot; or &quot;exceptions&quot;. Talking about the latter only hide=
s the underlying issue, and if we get Contracts as a language feature, you =
could pick your poison without needing duplicate forms of the same function=
.. I&#39;d never encourage throwing on precondition violations, but you can =
go right ahead and do so if you wanted to. The more important thing we need=
 to establish, in my opinion, are proper guidelines on when and why a contr=
act should be made wide rather than narrow, and ideally default to narrow i=
f no rationale for widening is given. We can easily widen a contract in the=
 future but we cannot easily narrow. A wide contract also adds more complex=
ity.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In the case of std:=
:function, what are your expected uses for this contract being wide where t=
he user doesn&#39;t simply have a bug in their code? Similarly, answer the =
same question but for accessing the target of null a unique_ptr. In what re=
alistic cases are either of these *not* a developer&#39;s error?</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Separately, while I&#39;m not pers=
onally a fan of vector::at (you will notably find that view is not at all u=
ncommon in the committee and also outside of the committee), but at least f=
or &quot;at&quot; one can make an argument that the index may be coming mor=
e directly from user input and can at least &quot;recover&quot; by getting =
different input. Even there I&#39;d argue against it and the user should si=
mply check rather than using an exception for basic control flow, but it&#3=
9;s at least more defensible than throwing on the invocation of an empty st=
d::function. </div></div></blockquote><div><br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">In what scena=
rio is the invocation of a std::function anything other than a developer&#3=
9;s bug?</div></div></blockquote><div><br></div><div>When the target functi=
on address injected into the std::function has been loaded from a shared li=
brary, which turned out not to support it, for starters.</div><div><br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEk55Dy39HqbGzhqgZ2oB45gSQ8i7YMU=
bcxcuvLsBOq0Yw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-=
<wbr>proposals/<wbr>CANh8DEk55Dy39HqbGzhqgZ2oB45gS<wbr>Q8i7YMUbcxcuvLsBOq0Y=
w%40mail.<wbr>gmail.com</a>.<br>
</blockquote></div><br></div></div>

<p></p>

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

--000000000000b60896056a97a09f--

.

--000000000000b7d4f1056a97b597
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 08:36 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> On Tuesday, April 24, 2018 at 3:28:27 PM UTC+3, Matt Calabrese wrote:
>>
>> On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.d...@gmail.com>
>> wrote:
>>
>>> "Bug" is a really high-level concept. Exception is not a bug if handled
>>> thoroughly.
>>>
>>
>> I've never said that an exception is a bug.
>>
>> On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.d...@gmail.com>
>> wrote:
>>
>>> E.g. is bad_alloc is bug in implemetation? Or is it fatal error? No if
>>> you have "plan B" - an alternative algorithm that is slower but can be done
>>> with less memory.
>>>
>>
>> I never said, nor would I say, that bad_alloc is a bug.
>>
>
> So what is the difference with std::bad_function_call case?
>

Because the user cannot know in advance if any given call to new will fail.
The caller can make a perfectly rational call to new and the implementation
just simply cannot allocate them that much memory.

On Tue, Apr 24, 2018, 08:36 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> The point is that in std::function::operator() you really don't know if it
> is bug for user or it will be handled well.
>

What do you mean that you do not know if it is a bug or not? If the user
knew that the std::function were empty, then why would he invoke the
function? This is a bug and the caller is already in an unexpected program
state. Alternatively, the user is invoking the std::function intentionally
when the function *might* be empty, in which case they could replace their
"try" with "if" since they are using exceptions for basic control flow.
Again, both of these situations are just misuses of exceptions.

--
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/CANh8DE%3Dxp7ppZi_tbpKUD0sEmv%2BhrrCrs-P9QuFqZ3-9K-nrVA%40mail.gmail.com.

--000000000000b7d4f1056a97b597
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
Apr 24, 2018, 08:36 Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko=
@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 3:28:27 P=
M UTC+3, Matt Calabrese 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"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 2=
4, 2018, 08:04 Victor Dyachenko &lt;<a rel=3D"nofollow noreferrer">victor.d=
....@gmail.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>&quot;Bug&quot; is a really high-level concept. Exception is =
not a bug if handled thoroughly.</div></div></blockquote></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve never said that an excepti=
on is a bug.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><span style=
=3D"font-family:sans-serif">On Tue, Apr 24, 2018, 08:04 Victor Dyachenko &l=
t;<a rel=3D"nofollow noreferrer">victor.d...@gmail.com</a>&gt; wrote:</span=
><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>E.g. is bad_alloc is bug in implemetati=
on? Or is it fatal error? No if you have &quot;plan B&quot; - an alternativ=
e algorithm that is slower but can be done with less memory.<br></div></div=
></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I n=
ever said, nor would I say, that bad_alloc is a bug.<br></div></div></block=
quote><div><br>So what is the difference with std::bad_function_call case?<=
/div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Because the user cannot know in advance if any given call to new wil=
l fail. The caller can make a perfectly rational call to new and the implem=
entation just simply cannot allocate them that much memory.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><span style=3D"font-family:sans-serif=
">On Tue, Apr 24, 2018, 08:36 Victor Dyachenko &lt;<a href=3D"mailto:victor=
..dyachenko@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:</span><br><=
/div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>The point is that in std::function::operator() =
you really don&#39;t know if it is bug for user or it will be handled well.=
</div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">What do you mean that you do not know if it is a bug or not? If t=
he user knew that the std::function were empty, then why would he invoke th=
e function? This is a bug and the caller is already in an unexpected progra=
m state. Alternatively, the user is invoking the std::function intentionall=
y when the function *might* be empty, in which case they could replace thei=
r &quot;try&quot; with &quot;if&quot; since they are using exceptions for b=
asic control flow. Again, both of these situations are just misuses of exce=
ptions.</div></div>

<p></p>

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

--000000000000b7d4f1056a97b597--

.

--0000000000007d5e0b056a97caf4
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 08:52 Richard Hodges <hodges.r@gmail.com> wrote:

> In what scenario is the invocation of a std::function anything other than
>> a developer's bug?
>>
>
> When the target function address injected into the std::function has been
> loaded from a shared library, which turned out not to support it, for
> starters.
>

And the user cannot simply check this because...?

--
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/CANh8DEkk3s_%3DO6h65nkjJhNCpK-JR5sjW_21S11s75ubfU13ZA%40mail.gmail.com.

--0000000000007d5e0b056a97caf4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr">On Tue, Apr 24, 2018, 08:52 Richard Hodges &lt;<a href=3D"mailto:h=
odges.r@gmail.com">hodges.r@gmail.com</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto=
">In what scenario is the invocation of a std::function anything other than=
 a developer&#39;s bug?</div></div></blockquote><div><br></div><div>When th=
e target function address injected into the std::function has been loaded f=
rom a shared library, which turned out not to support it, for starters.</di=
v></div></div></div></blockquote></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">And the user cannot simply check this because...?</div><div class=
=3D"gmail_quote" dir=3D"auto"></div></div>

<p></p>

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

--0000000000007d5e0b056a97caf4--

.

------=_Part_16958_1007771094.1524575579696
Content-Type: multipart/alternative;
 boundary="----=_Part_16959_1548596850.1524575579697"

------=_Part_16959_1548596850.1524575579697
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 3:49:45 PM UTC+3, Matt Calabrese wrote:
>
>
>
> On Tue, Apr 24, 2018, 08:16 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, April 24, 2018 at 2:56:36 PM UTC+3, Matt Calabrese wrote:
>>>
>>>
>>> An example of a solid use of an exception is to communicate when a
>>> function simply cannot reach its postcondition but where the caller did not
>>> violate a contract.
>>>
>>
>> So it's perfectly OK to throw in the case of std::function. It can't
>> reach it's postcondition (call the wrapped function) because no function
>> has been given. And exception is fully defined behavior in contrast to
>> access to uninitialized memory.
>>
>
> This is why I said we should focus the discussion on whether we should
> make contracts narrow or wide rather than on whether we should have "UB" or
> "exceptions". Talking about the latter only hides the underlying issue, and
> if we get Contracts as a language feature, you could pick your poison
> without needing duplicate forms of the same function. I'd never encourage
> throwing on precondition violations, but you can go right ahead and do so
> if you wanted to. The more important thing we need to establish, in my
> opinion, are proper guidelines on when and why a contract should be made
> wide rather than narrow, and ideally default to narrow if no rationale for
> widening is given. We can easily widen a contract in the future but we
> cannot easily narrow. A wide contract also adds more complexity.
>
> In the case of std::function, what are your expected uses for this
> contract being wide where the user doesn't simply have a bug in their code?
> Similarly, answer the same question but for accessing the target of null a
> unique_ptr. In what realistic cases are either of these *not* a developer's
> error?
>
> Separately, while I'm not personally a fan of vector::at (you will notably
> find that view is not at all uncommon in the committee and also outside of
> the committee), but at least for "at" one can make an argument that the
> index may be coming more directly from user input and can at least
> "recover" by getting different input. Even there I'd argue against it and
> the user should simply check rather than using an exception for basic
> control flow, but it's at least more defensible than throwing on the
> invocation of an empty std::function. In what scenario is the invocation of
> a std::function anything other than a developer's bug?
>

Example with std::vector instead of std::function:

void zero_all(std::vector<int> &v)
{
    try {
        for(int i = 0;;) v.at(i++) = 0;
    } catch(std::out_of_range) {
        // done
    }
}

Yes it looks stupid because it's trivial and there are better alternatives.
But it's totally valid and functional.

Disclamer: I have never used vector::at() in my life in my code :-) (use
C++ for 15 years)

All I want to say is that the world is complicated and never one size fits
all. I personally prefer manual checks and fast interfaces like
vector::operator[] and optional::operator* used with Hoare tripples in the
mind. But there are people that happy with pseudo-safe interfaces. Don't
see why should we restrict them.

--
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/70a8bdc1-5a73-4474-9cd3-00c57be934cb%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 3:49:45 PM UTC+3, Matt Calab=
rese 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"auto"><=
div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 24, 201=
8, 08:16 Victor Dyachenko &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"QE0bTtXyAwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">victor.d...@gmail.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, April 24, 2018 at 2=
:56:36 PM UTC+3, Matt Calabrese 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"auto"><br><div dir=3D"auto">An example of a solid use of an =
exception is to communicate when a function simply cannot reach its postcon=
dition but where the caller did not violate a contract.</div></div></blockq=
uote><div><br>So it&#39;s perfectly OK to throw in the case of std::functio=
n. It can&#39;t reach it&#39;s postcondition (call the wrapped function) be=
cause no function has been given. And exception is fully defined behavior i=
n contrast to access to uninitialized memory.<br></div></div></blockquote><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is why I said=
 we should focus the discussion on whether we should make contracts narrow =
or wide rather than on whether we should have &quot;UB&quot; or &quot;excep=
tions&quot;. Talking about the latter only hides the underlying issue, and =
if we get Contracts as a language feature, you could pick your poison witho=
ut needing duplicate forms of the same function. I&#39;d never encourage th=
rowing on precondition violations, but you can go right ahead and do so if =
you wanted to. The more important thing we need to establish, in my opinion=
, are proper guidelines on when and why a contract should be made wide rath=
er than narrow, and ideally default to narrow if no rationale for widening =
is given. We can easily widen a contract in the future but we cannot easily=
 narrow. A wide contract also adds more complexity.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">In the case of std::function, what are your exp=
ected uses for this contract being wide where the user doesn&#39;t simply h=
ave a bug in their code? Similarly, answer the same question but for access=
ing the target of null a unique_ptr. In what realistic cases are either of =
these *not* a developer&#39;s error?</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Separately, while I&#39;m not personally a fan of vector::at (=
you will notably find that view is not at all uncommon in the committee and=
 also outside of the committee), but at least for &quot;at&quot; one can ma=
ke an argument that the index may be coming more directly from user input a=
nd can at least &quot;recover&quot; by getting different input. Even there =
I&#39;d argue against it and the user should simply check rather than using=
 an exception for basic control flow, but it&#39;s at least more defensible=
 than throwing on the invocation of an empty std::function. In what scenari=
o is the invocation of a std::function anything other than a developer&#39;=
s bug?</div></div></blockquote><div><br>Example with std::vector instead of=
 std::function:<br><br><span style=3D"font-family: courier\ new, monospace;=
">void zero_all(std::vector&lt;int&gt; &amp;v)<br>{<br>=C2=A0=C2=A0=C2=A0 t=
ry {<br>=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 for(int i =3D 0;;) v.at(i++) =3D 0=
;<br>=C2=A0=C2=A0=C2=A0 } catch(std::out_of_range) {<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 // done<br>=C2=A0=C2=A0=C2=A0 }<br>}<br></span><br=
>Yes it looks stupid because it&#39;s trivial and there are better alternat=
ives. But it&#39;s totally valid and functional.<br><br>Disclamer: I have n=
ever used vector::at() in my life in my code :-) (use C++ for 15 years)<br>=
<br>All I want to say is that the world is complicated and never one size f=
its all.  I personally prefer manual checks and fast interfaces like vector=
::operator[] and optional::operator* used with Hoare tripples in the mind. =
But there are people that happy with pseudo-safe interfaces. Don&#39;t see =
why should we restrict them.<br></div></div>

<p></p>

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

------=_Part_16959_1548596850.1524575579697--

------=_Part_16958_1007771094.1524575579696--

.

------=_Part_29180_1944350515.1524575920885
Content-Type: multipart/alternative;
 boundary="----=_Part_29181_1194747873.1524575920885"

------=_Part_29181_1194747873.1524575920885
Content-Type: text/plain; charset="UTF-8"

By the way, Matt. What do you think about std::visit()? Shouldn't it throw
std::bad_variant_access and must we all the time write

if(!v.valueless_by_exception()) std::visit(v, my_visitor{});

?

--
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/2e49a6ab-8cb9-4f38-85dc-77d494a10b64%40isocpp.org.

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

<div dir=3D"ltr">By the way, Matt. What do you think about std::visit()? Sh=
ouldn&#39;t it throw std::bad_variant_access and must we all the time write=
<br><br><span style=3D"font-family: courier\ new, monospace;">if(!v.valuele=
ss_by_exception()) std::visit(v, my_visitor{});</span><br><br>?<br></div>

<p></p>

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

------=_Part_29181_1194747873.1524575920885--

------=_Part_29180_1944350515.1524575920885--

.

------=_Part_16565_2114816281.1524576232008
Content-Type: multipart/alternative;
 boundary="----=_Part_16566_470336392.1524576232008"

------=_Part_16566_470336392.1524576232008
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 3:58:27 PM UTC+3, Matt Calabrese wrote:
>
> On Tue, Apr 24, 2018, 08:36 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> The point is that in std::function::operator() you really don't know if
>> it is bug for user or it will be handled well.
>>
>
> What do you mean that you do not know if it is a bug or not?
>
I mean if you a the writer of std::function not the user. They are
different people usually :-)

--
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/7b3cf9b3-664b-4fd0-ba45-fba6f0006a1f%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 3:58:27 PM UTC+3, Matt Calab=
rese 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"auto"><=
div dir=3D"auto"><span style=3D"font-family:sans-serif">On Tue, Apr 24, 201=
8, 08:36 Victor Dyachenko &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"J_Bdpk7zAwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">victor.d...@gmail.com</a>&gt; wrote:</span><br></d=
iv><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>The point is that in std::function::operator() yo=
u really don&#39;t know if it is bug for user or it will be handled well.</=
div></div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">What do you mean that you do not know if it is a bug or not?</div></d=
iv></blockquote><div>I mean if you a the writer of std::function not the us=
er. They are different people usually :-)<br></div></div>

<p></p>

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

------=_Part_16566_470336392.1524576232008--

------=_Part_16565_2114816281.1524576232008--

.

--000000000000902bce056a98aa0c
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018, 09:18 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> By the way, Matt. What do you think about std::visit()?
>

I was against an exception being thrown there when in the valueless by
exception state. It should be a precondition violation. I also had much
broader objections to the valueless by exception state and how it is dealt
with.

On Tue, Apr 24, 2018, 09:18 Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> Shouldn't it throw std::bad_variant_access and must we all the time write
>
> if(!v.valueless_by_exception()) std::visit(v, my_visitor{});
>

You wouldn't write that everywhere that you use visit -- you would either
a) be in a situation where you could not possibly have a variant in the
valueless by exception state at the point at which you call std::visit, or
b) if your function receives the variant as an argument that you need to
visit, you yourself could/should specify as a precondition that the variant
must not be in the valueless by exception state (this is not at all a
strange requirement and is akin to requiring that a scalar parameter is
initialized), or c) if you genuinely need to allow a variant in the
valueless by exception state to be passed in to your function (or you
somehow just have one locally that may or may not be in that state) and you
choose to branch, performing a visit in one case and doing something else
in the other, then you can write a branch.

--
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/CANh8DE%3DFDKk9saX0vSVrNCE3hE76QTQ-KUKFW9voxW%3DVLpnGQQ%40mail.gmail.com.

--000000000000902bce056a98aa0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, Apr 24, 2018, 09:18 Victor Dyachenko &lt;<a href=3D"mailto=
:victor.dyachenko@gmail.com" target=3D"_blank">victor.dyachenko@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">By t=
he way, Matt. What do you think about std::visit()?</div></blockquote><div>=
<br></div><div>I was against an exception being thrown there when in the va=
lueless by exception state. It should be a precondition violation. I also h=
ad much broader objections to the valueless by exception state and how it i=
s dealt with.</div><div><br></div><div><span style=3D"color:rgb(34,34,34);f=
ont-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatur=
es:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;te=
xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial=
;text-decoration-color:initial;float:none;display:inline">On Tue, Apr 24, 2=
018, 09:18 Victor Dyachenko &lt;</span><a href=3D"mailto:victor.dyachenko@g=
mail.com" target=3D"_blank" style=3D"color:rgb(17,85,204);font-family:sans-=
serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-v=
ariant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;back=
ground-color:rgb(255,255,255)">victor.dyachenko@gmail.com</a><span style=3D=
"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:norma=
l;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;le=
tter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-de=
coration-style:initial;text-decoration-color:initial;float:none;display:inl=
ine">&gt; wrote:</span>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"> Shouldn&#39;t it throw std::bad_variant_access and must we all th=
e time write<br><br><span>if(!v.valueless_by_exception()) std::visit(v, my_=
visitor{});</span></div></blockquote><div><br></div><div>You wouldn&#39;t w=
rite that everywhere that you use visit -- you would either a) be in a situ=
ation where you could not possibly have a variant in the valueless by excep=
tion state at the point at which you call std::visit, or b) if your functio=
n receives the variant as an argument that you need to visit, you yourself =
could/should specify as a precondition that the variant must not be in the =
valueless by exception state (this is not at all a strange requirement and =
is akin to requiring that a scalar parameter is initialized), or c) if you =
genuinely need to allow a variant in the valueless by exception state to be=
 passed in to your function (or you somehow just have one locally that may =
or may not be in that state) and you choose to branch, performing a visit i=
n one case and doing something else in the other, then you can write a bran=
ch.</div></div></div></div></div>

<p></p>

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

--000000000000902bce056a98aa0c--

.

--00000000000064459b056a98bebb
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> Yes it looks stupid because it's trivial and there are better alternatives.
>

Yes.

On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> Disclamer: I have never used vector::at() in my life in my code :-) (use
> C++ for 15 years)
>

I would consider that alone a very useful data point.

On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko <victor.dyachenko@gmail.com>
wrote:

> All I want to say is that the world is complicated and never one size fits
> all. I personally prefer manual checks and fast interfaces like
> vector::operator[] and optional::operator* used with Hoare tripples in the
> mind. But there are people that happy with pseudo-safe interfaces. Don't
> see why should we restrict them.
>

Because they are only "pseudo" safe and in practice people jump to them as
the "safe" option by default, and I think that actually does more harm than
good with respect to safety. We also pay for these both in complexity in
specification (duplicate interfaces), and in teachability (which form would
you tell a newcomer to use and why -- I would never tell a newcomer to
default to using a form std::function's operator() that throws on empty
were there the other option).

--
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/CANh8DEk9N%3DC2jeTaJyz9B%2BLTAQyR38gNLQ-pNazfmiMHQkzZVg%40mail.gmail.com.

--00000000000064459b056a98bebb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 24=
, 2018 at 9:13 AM Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko@g=
mail.com">victor.dyachenko@gmail.com</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>Yes it looks stupid because it&#39;s tr=
ivial and there are better alternatives.<br></div></div></blockquote><div><=
br></div><div>Yes.</div><div><br></div><div><span style=3D"color:rgb(34,34,=
34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-li=
gatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:in=
itial;text-decoration-color:initial;float:none;display:inline">On Tue, Apr =
24, 2018 at 9:13 AM Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko=
@gmail.com">victor.dyachenko@gmail.com</a>&gt; wrote:</span>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Disclamer: I have never u=
sed vector::at() in my life in my code :-) (use C++ for 15 years)<br></div>=
</div></blockquote><div><br></div><div>I would consider that alone a very u=
seful data point.</div><div>=C2=A0<br class=3D"gmail-Apple-interchange-newl=
ine"><span style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13=
px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal=
;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(2=
55,255,255);text-decoration-style:initial;text-decoration-color:initial;flo=
at:none;display:inline">On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko &l=
t;<a href=3D"mailto:victor.dyachenko@gmail.com">victor.dyachenko@gmail.com<=
/a>&gt; wrote:</span></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>All I want to say is that the world is complicated and never one size =
fits all.  I personally prefer manual checks and fast interfaces like vecto=
r::operator[] and optional::operator* used with Hoare tripples in the mind.=
 But there are people that happy with pseudo-safe interfaces. Don&#39;t see=
 why should we restrict them.<br></div></div></blockquote><div><br></div><d=
iv>Because they are only &quot;pseudo&quot; safe and in practice people jum=
p to them as the &quot;safe&quot; option by default, and I think that actua=
lly does more harm than good with respect to safety. We also pay for these =
both in complexity in specification (duplicate interfaces), and in teachabi=
lity (which form would you tell a newcomer to use and why -- I would never =
tell a newcomer to default to using a form std::function&#39;s operator() t=
hat throws on empty were there the other option).</div></div></div>

<p></p>

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

--00000000000064459b056a98bebb--

.

On Tuesday, 24 April 2018 04:35:23 PDT Victor Dyachenko wrote:
> > IMHO, the "safety" argument is an illusion, unless you actually want that
> > exception in one of your use cases, which I find hard to believe.
>
> By "safety"  I mean "fail-fast". All we can misunderstand the code.
> Exception is usually much more better than subsequent segfault in other
> piece of code. And even more better than silent data corruption.

That's an illusion.

Your argument was that junior C++ developers would more likely use the "safe"
functions because they throw. Those developers are far more likely to put a
big catch (std::exception e) or catch (...) and attempt to continue. Thus your
bug gets hidden, instead of being immediately flagged.

Worse, because it got hidden, the initial bug can lead to further issues, like
data corruption and data loss.

I'm not saying this will happen in every case. Neither am I saying that
exceptions should be avoided -- they have their uses. I am saying that
exceptions are not a guarantee to better code. Better code requires, well,
better code.

--
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/3278542.RlYs4Azo9m%40tjmaciei-mobl1.

.

--000000000000058a21056a9b8859
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018 at 10:06 AM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Tue, Apr 24, 2018, 09:18 Victor Dyachenko <victor.dyachenko@gmail.com>
> wrote:
>
>> By the way, Matt. What do you think about std::visit()?
>>
>
> I was against an exception being thrown there when in the valueless by
> exception state. It should be a precondition violation. I also had much
> broader objections to the valueless by exception state and how it is dealt
> with.
>
> On Tue, Apr 24, 2018, 09:18 Victor Dyachenko <victor.dyachenko@gmail.com>
> wrote:
>
>> Shouldn't it throw std::bad_variant_access and must we all the time write
>>
>> if(!v.valueless_by_exception()) std::visit(v, my_visitor{});
>>
>
> You wouldn't write that everywhere that you use visit -- you would either
> a) be in a situation where you could not possibly have a variant in the
> valueless by exception state at the point at which you call std::visit, or
> b) if your function receives the variant as an argument that you need to
> visit, you yourself could/should specify as a precondition that the variant
> must not be in the valueless by exception state (this is not at all a
> strange requirement and is akin to requiring that a scalar parameter is
> initialized), or c) if you genuinely need to allow a variant in the
> valueless by exception state to be passed in to your function (or you
> somehow just have one locally that may or may not be in that state) and you
> choose to branch, performing a visit in one case and doing something else
> in the other, then you can write a branch.
>
>
+1

You should almost never check valueless_by_exception.  If you need to check
it at all, it should probably be in a catch() clause, for the exception
that caused it to become valueless.
And 99 times out of 100, that exception will bubble up to a point where the
variant is destroyed, thus no need to check.

Outside that 1% catch() case, you should probably never check
valueless_by_exception.

Also, it will only get into that state because some move-operation threw.
Which should never happen.  (Because move ops should be noexcept, and the
few that aren't are only trying to allocate a small amount of bytes, so if
that fails, you probably have bigger problems.)

So you should just ignore valueless_by_exception (beyond documenting its
non-existence as a precondition - probably globally "all functions dealing
with vairant assume !valueless_by_exception...).

--
Be seeing you,
Tony

--
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/CAOHCbisb53DOdYGsgSFfqr_YPmqKBF%2Bo9j3LLGkbk0D3oT143Q%40mail.gmail.com.

--000000000000058a21056a9b8859
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Apr 24, 2018 at 10:06 AM, &#39;Matt Calabrese&#39; via ISO C++ =
Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-pro=
posals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"aut=
o"><div><div class=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Tue=
, Apr 24, 2018, 09:18 Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachen=
ko@gmail.com" target=3D"_blank">victor.dyachenko@gmail.com</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">By the way, Matt. W=
hat do you think about std::visit()?</div></blockquote><div><br></div></spa=
n><div>I was against an exception being thrown there when in the valueless =
by exception state. It should be a precondition violation. I also had much =
broader objections to the valueless by exception state and how it is dealt =
with.</div><span class=3D""><div><br></div><div><span style=3D"color:rgb(34=
,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-varian=
t-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-styl=
e:initial;text-decoration-color:initial;float:none;display:inline">On Tue, =
Apr 24, 2018, 09:18 Victor Dyachenko &lt;</span><a href=3D"mailto:victor.dy=
achenko@gmail.com" style=3D"color:rgb(17,85,204);font-family:sans-serif;fon=
t-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-ca=
ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255)" target=3D"_blank">victor.dyachenko@gmail.com</a><span=
 style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-st=
yle:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weig=
ht:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255=
);text-decoration-style:initial;text-decoration-color:initial;float:none;di=
splay:inline">&gt; wrote:</span>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"> Shouldn&#39;t it throw std::bad_variant_access and must w=
e all the time write<br><br><span>if(!v.valueless_by_exception()<wbr>) std:=
:visit(v, my_visitor{});</span></div></blockquote><div><br></div></span><di=
v>You wouldn&#39;t write that everywhere that you use visit -- you would ei=
ther a) be in a situation where you could not possibly have a variant in th=
e valueless by exception state at the point at which you call std::visit, o=
r b) if your function receives the variant as an argument that you need to =
visit, you yourself could/should specify as a precondition that the variant=
 must not be in the valueless by exception state (this is not at all a stra=
nge requirement and is akin to requiring that a scalar parameter is initial=
ized), or c) if you genuinely need to allow a variant in the valueless by e=
xception state to be passed in to your function (or you somehow just have o=
ne locally that may or may not be in that state) and you choose to branch, =
performing a visit in one case and doing something else in the other, then =
you can write a branch.</div></div></div></div></div><span class=3D"">

<p></p></span></blockquote><div><br clear=3D"all"></div></div>+1<br><br></d=
iv><div class=3D"gmail_extra">You should almost never check valueless_by_ex=
ception.=C2=A0 If you need to check it at all, it should probably be in a c=
atch() clause, for the exception that caused it to become valueless.<br></d=
iv><div class=3D"gmail_extra">And 99 times out of 100, that exception will =
bubble up to a point where the variant is destroyed, thus no need to check.=
<br><br></div><div class=3D"gmail_extra">Outside that 1% catch() case, you =
should probably never check valueless_by_exception.<br><br></div><div class=
=3D"gmail_extra">Also, it will only get into that state because some move-o=
peration threw.=C2=A0 Which should never happen.=C2=A0 (Because move ops sh=
ould be noexcept, and the few that aren&#39;t are only trying to allocate a=
 small amount of bytes, so if that fails, you probably have bigger problems=
..)<br><br></div><div class=3D"gmail_extra">So you should just ignore valuel=
ess_by_exception (beyond documenting its non-existence as a precondition - =
probably globally &quot;all functions dealing with vairant assume !valueles=
s_by_exception...).<br><br></div><div class=3D"gmail_extra">-- <br><div cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
<div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

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

--000000000000058a21056a9b8859--

.

--000000000000105f7c056a9bfcfe
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018 at 10:12 AM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko <
> victor.dyachenko@gmail.com> wrote:
>
>> Yes it looks stupid because it's trivial and there are better
>> alternatives.
>>
>
> Yes.
>
> On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko <
> victor.dyachenko@gmail.com> wrote:
>
>> Disclamer: I have never used vector::at() in my life in my code :-) (use
>> C++ for 15 years)
>>
>
> I would consider that alone a very useful data point.
>
> On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko <
> victor.dyachenko@gmail.com> wrote:
>
>> All I want to say is that the world is complicated and never one size
>> fits all. I personally prefer manual checks and fast interfaces like
>> vector::operator[] and optional::operator* used with Hoare tripples in the
>> mind. But there are people that happy with pseudo-safe interfaces. Don't
>> see why should we restrict them.
>>
>
> Because they are only "pseudo" safe and in practice people jump to them as
> the "safe" option by default, and I think that actually does more harm than
> good with respect to safety. We also pay for these both in complexity in
> specification (duplicate interfaces), and in teachability (which form would
> you tell a newcomer to use and why -- I would never tell a newcomer to
> default to using a form std::function's operator() that throws on empty
> were there the other option).
>
>
>
Whenever a function detects "disappointment" (ie the inability to succeed
in its primary purpose), it probably needs to communicate this
disappointment to someone(s):

F - the developer that wrote the Function (ie "whoops! this should never
happen, but it did - internal state error")
D - the Developer that called the function (ie "you passed null, but I told
you never to do that")
C - the Code that called the function (ie "sorry the file cannot be found")
U - the user

(I'll let readers reorder those and form their own acronym)

Note, importantly, the difference between D and C - the developer that
wrote the code, and the code itself.  If you detect that the Developer
called the function wrong, there's not much sense telling the Code. It's
wrong.  You want to tell the Developer.

You tell the Code via return codes and/or exceptions.  (The Code then
likely tells the User)
You tell the Developer via asserts and logs. (And crashing or some kind of
"Panic-Save" informs the User)

Now, unfortunately, it is the function (and thus F - the Function author)
that decides who and thus how to tell.  Yet the function author doesn't
know.  Is "file not found" a user error (because the user typed it in) or a
Developer error, because the Developer hard-coded the wrong config-file
name?  The fileOpen() function can't tell.

Nonetheless, until/unless we change error reporting, it is up to the
Function author to decide, by guessing.  Typically based on expected use.

So, for std::function, the question is - if someone calls a std::function,
and it is null, what are the chances this was a Developer bug?
Today, we don't *know* it is a developer bug (because it is well defined
behaviour), but from experience I would guess it is a Developer bug.

So the right answer would have been to not throw, but assert, ie crash, ie
make it a pre-condition.
The only question is whether we can change it.


P.S. for the "performance" argument, it has always been assumed that
std::function had enough overhead such that the null-check didn't really
make any difference.

--
Be seeing you,
Tony

--
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/CAOHCbiv2cKsSX5YvpL4Vmje8uVtMaS%3DiPEq%2BsLN4A5AdPFGzpA%40mail.gmail.com.

--000000000000105f7c056a9bfcfe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Apr 24, 2018 at 10:12 AM, &#39;Matt Calabrese&#39; via ISO C++ =
Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-pro=
posals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_quote"><span class=3D""><div dir=3D"ltr">On Tue, Apr 24, 2018 at 9:13 =
AM Victor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko@gmail.com" targe=
t=3D"_blank">victor.dyachenko@gmail.com</a>&gt; wrote:</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Yes it looks stupid because it&#39;s =
trivial and there are better alternatives.<br></div></div></blockquote><div=
><br></div></span><div>Yes.</div><span class=3D""><div><br></div><div><span=
 style=3D"color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-st=
yle:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weig=
ht:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255=
);text-decoration-style:initial;text-decoration-color:initial;float:none;di=
splay:inline">On Tue, Apr 24, 2018 at 9:13 AM Victor Dyachenko &lt;<a href=
=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">victor.dyachenko@g=
mail.com</a>&gt; wrote:</span>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>Disclamer: I have never used vector::at() in my life in=
 my code :-) (use C++ for 15 years)<br></div></div></blockquote><div><br></=
div></span><div>I would consider that alone a very useful data point.</div>=
<span class=3D""><div>=C2=A0<br class=3D"m_-2419942583848378437gmail-Apple-=
interchange-newline"><span style=3D"color:rgb(34,34,34);font-family:sans-se=
rif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-var=
iant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;tex=
t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgr=
ound-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-c=
olor:initial;float:none;display:inline">On Tue, Apr 24, 2018 at 9:13 AM Vic=
tor Dyachenko &lt;<a href=3D"mailto:victor.dyachenko@gmail.com" target=3D"_=
blank">victor.dyachenko@gmail.com</a>&gt; wrote:</span></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>All I want to say is that the world =
is complicated and never one size fits all.  I personally prefer manual che=
cks and fast interfaces like vector::operator[] and optional::operator* use=
d with Hoare tripples in the mind. But there are people that happy with pse=
udo-safe interfaces. Don&#39;t see why should we restrict them.<br></div></=
div></blockquote><div><br></div></span><div>Because they are only &quot;pse=
udo&quot; safe and in practice people jump to them as the &quot;safe&quot; =
option by default, and I think that actually does more harm than good with =
respect to safety. We also pay for these both in complexity in specificatio=
n (duplicate interfaces), and in teachability (which form would you tell a =
newcomer to use and why -- I would never tell a newcomer to default to usin=
g a form std::function&#39;s operator() that throws on empty were there the=
 other option).</div></div></div><span class=3D"">

<p></p></span><br clear=3D"all"></blockquote></div><br></div><div class=3D"=
gmail_extra">Whenever a function detects &quot;disappointment&quot; (ie the=
 inability to succeed in its primary purpose), it probably needs to communi=
cate this disappointment to someone(s):<br><br></div><div class=3D"gmail_ex=
tra">F - the developer that wrote the Function (ie &quot;whoops! this shoul=
d never happen, but it did - internal state error&quot;)<br></div><div clas=
s=3D"gmail_extra">D - the Developer that called the function (ie &quot;you =
passed null, but I told you never to do that&quot;)<br></div><div class=3D"=
gmail_extra">C - the Code that called the function (ie &quot;sorry the file=
 cannot be found&quot;)<br></div><div class=3D"gmail_extra">U - the user<br=
><br></div><div class=3D"gmail_extra">(I&#39;ll let readers reorder those a=
nd form their own acronym)<br><br></div><div class=3D"gmail_extra">Note, im=
portantly, the difference between D and C - the developer that wrote the co=
de, and the code itself.=C2=A0 If you detect that the Developer called the =
function wrong, there&#39;s not much sense telling the Code. It&#39;s wrong=
..=C2=A0 You want to tell the Developer.<br><br></div><div class=3D"gmail_ex=
tra">You tell the Code via return codes and/or exceptions.=C2=A0 (The Code =
then likely tells the User)<br></div><div class=3D"gmail_extra">You tell th=
e Developer via asserts and logs. (And crashing or some kind of &quot;Panic=
-Save&quot; informs the User)<br><br></div><div class=3D"gmail_extra">Now, =
unfortunately, it is the function (and thus F - the Function author) that d=
ecides who and thus how to tell.=C2=A0 Yet the function author doesn&#39;t =
know.=C2=A0 Is &quot;file not found&quot; a user error (because the user ty=
ped it in) or a Developer error, because the Developer hard-coded the wrong=
 config-file name?=C2=A0 The fileOpen() function can&#39;t tell.<br><br></d=
iv><div class=3D"gmail_extra">Nonetheless, until/unless we change error rep=
orting, it is up to the Function author to decide, by guessing.=C2=A0 Typic=
ally based on expected use.<br><br></div><div class=3D"gmail_extra">So, for=
 std::function, the question is - if someone calls a std::function, and it =
is null, what are the chances this was a Developer bug?<br></div><div class=
=3D"gmail_extra">Today, we don&#39;t *know* it is a developer bug (because =
it is well defined behaviour), but from experience I would guess it is a De=
veloper bug.<br><br></div><div class=3D"gmail_extra">So the right answer wo=
uld have been to not throw, but assert, ie crash, ie make it a pre-conditio=
n.<br></div><div class=3D"gmail_extra">The only question is whether we can =
change it.<br><br><br></div><div class=3D"gmail_extra">P.S. for the &quot;p=
erformance&quot; argument, it has always been assumed that std::function ha=
d enough overhead such that the null-check didn&#39;t really make any diffe=
rence.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signatur=
e"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>

<p></p>

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

--000000000000105f7c056a9bfcfe--

.

On 04/24/18 15:36, Victor Dyachenko wrote:
> On Tuesday, April 24, 2018 at 3:28:27 PM UTC+3, Matt Calabrese wrote:
>
>     On Tue, Apr 24, 2018, 08:04 Victor Dyachenko <victor.d...@gmail.com>
>     wrote:
>
>         E.g. is bad_alloc is bug in implemetation? Or is it fatal error?
>         No if you have "plan B" - an alternative algorithm that is
>         slower but can be done with less memory.
>
>
>     I never said, nor would I say, that bad_alloc is a bug.
>
>
> So what is the difference with std::bad_function_call case?

The difference is that `operator new` throws because it could not
complete its function for no user's fault (i.e. its precondition is not
violated). You cannot reasonably define a precondition like "there must
be enough free memory for the function to complete" because there
generally is no way the user could fulfill it.
`std::function::operator()` throws for no apparent reason only because
the precondition "the function object is not empty" is not defined. Such
precondition is perfectly achievable by users and in other cases
(smart-pointers) is defined.

--
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/a49e8729-cfee-e137-27cc-934f51aaeb5b%40gmail.com.

.

On 04/24/18 14:35, Victor Dyachenko wrote:
>=20
>=20
> On Tuesday, April 24, 2018 at 1:23:06 PM UTC+3, Andrey Semashev wrote:
>=20
>     Why must it be uglier?
>=20
> To be friendlier to juniors and other non-experts. C++ can be used not=20
> only by programmers but by other people who just need to use comuter.

This "friendliness" does a mis-service to the C++ newcomers as it=20
teaches the wrong thing - throw on bugs.

>     IMHO, the "safety" argument is an illusion, unless you actually want
>     that
>     exception in one of your use cases, which I find hard to believe.
>=20
> By "safety"=C2=A0 I mean "fail-fast". All we can misunderstand the code.=
=20
> Exception is usually much more better than subsequent segfault in other=
=20
> piece of code. And even more better than silent data corruption.

As Matt Calabrese said, throwing is not failing fast, crashing is. I=20
always want my code crash ASAP if I have a bug because this way I can at=20
least have a backtrace and fix the bug. With an exception it is at best=20
logged, and then missed.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a4e038af-9d6d-c0b5-b221-1e7da5ef4109%40gmail.com=
..

.

------=_Part_28793_757238516.1524640508361
Content-Type: multipart/alternative;
 boundary="----=_Part_28794_1440510312.1524640508361"

------=_Part_28794_1440510312.1524640508361
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 7:01:12 PM UTC+3, Thiago Macieira wrote:
>
> On Tuesday, 24 April 2018 04:35:23 PDT Victor Dyachenko wrote:
> > > IMHO, the "safety" argument is an illusion, unless you actually want
> that
> > > exception in one of your use cases, which I find hard to believe.
> >
> > By "safety"  I mean "fail-fast". All we can misunderstand the code.
> > Exception is usually much more better than subsequent segfault in other
> > piece of code. And even more better than silent data corruption.
>
> That's an illusion.
>
> Your argument was that junior C++ developers would more likely use the
> "safe"
> functions because they throw. Those developers are far more likely to put
> a
> big catch (std::exception e) or catch (...) and attempt to continue. Thus
> your
> bug gets hidden, instead of being immediately flagged.
>

Memory corruptions usually not "immediately flagged". They hard to discover
because usually crash point is not the point of bug. And, yes, I worry
about juniors and other people who use C++ but are not professional
experienced programmers.

--
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/bf915467-abdb-4c75-add9-25df46d73efa%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 7:01:12 PM UTC+3, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 24 Apr=
il 2018 04:35:23 PDT Victor Dyachenko wrote:
<br>&gt; &gt; IMHO, the &quot;safety&quot; argument is an illusion, unless =
you actually want that
<br>&gt; &gt; exception in one of your use cases, which I find hard to beli=
eve.
<br>&gt;=20
<br>&gt; By &quot;safety&quot; =C2=A0I mean &quot;fail-fast&quot;. All we c=
an misunderstand the code.
<br>&gt; Exception is usually much more better than subsequent segfault in =
other
<br>&gt; piece of code. And even more better than silent data corruption.
<br>
<br>That&#39;s an illusion.
<br>
<br>Your argument was that junior C++ developers would more likely use the =
&quot;safe&quot;=20
<br>functions because they throw. Those developers are far more likely to p=
ut a=20
<br>big catch (std::exception e) or catch (...) and attempt to continue. Th=
us your=20
<br>bug gets hidden, instead of being immediately flagged.
<br></blockquote><div><br>Memory corruptions usually not &quot;immediately =
flagged&quot;. They hard to discover because usually crash point is not the=
 point of  bug. And, yes, I worry about juniors and other people who use C+=
+ but are not professional experienced programmers.<br></div></div>

<p></p>

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

------=_Part_28794_1440510312.1524640508361--

------=_Part_28793_757238516.1524640508361--

.

------=_Part_32029_1138792216.1524641045025
Content-Type: multipart/alternative;
 boundary="----=_Part_32030_1764640391.1524641045025"

------=_Part_32030_1764640391.1524641045025
Content-Type: text/plain; charset="UTF-8"

On Tuesday, April 24, 2018 at 9:19:13 PM UTC+3, Andrey Semashev wrote:
>
> As Matt Calabrese said, throwing is not failing fast, crashing is. I
> always want my code crash ASAP if I have a bug
>
So do I! But memory corruption is not immediate crash.

Writing code in C-style - if() in each row is:

1) Tedious,
2) It totally water down initial algorithm, the code is mostly "write
only", like asm.

--
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/3b34d760-85df-427a-8a8c-be3535510169%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, April 24, 2018 at 9:19:13 PM UTC+3, Andrey Sem=
ashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As Matt Calabrese =
said, throwing is not failing fast, crashing is. I=20
<br>always want my code crash ASAP if I have a bug<br></blockquote><div>So =
do I! But memory corruption is not immediate crash.<br><br>Writing code in =
C-style - if() in each row is:<br><br>1) Tedious,<br>2) It totally water do=
wn initial algorithm, the code is mostly &quot;write only&quot;, like asm.<=
br></div></div>

<p></p>

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

------=_Part_32030_1764640391.1524641045025--

------=_Part_32029_1138792216.1524641045025--

.

On 04/25/18 10:24, Victor Dyachenko wrote:
> On Tuesday, April 24, 2018 at 9:19:13 PM UTC+3, Andrey Semashev wrote:
>
>     As Matt Calabrese said, throwing is not failing fast, crashing is. I
>     always want my code crash ASAP if I have a bug
>
> So do I! But memory corruption is not immediate crash.

I don't think memory corruption is relevant, unless you initialize
`std::function` with a bogus pointer, from which the current check with
an exception don't protect. I would expect the empty state to be
implemented with a null pointer internally, calling which would result
in an immediate crash.

> Writing code in C-style - if() in each row is:
>
> 1) Tedious,

Not more tedious than typing `try`/`catch` blocks.

> 2) It totally water down initial algorithm, the code is mostly "write
> only", like asm.

Not sure what you mean here. During support and further development I
modify both the positive code and error handling quite often.

--
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/32262d4a-253f-6ad2-b570-e469569f71d4%40gmail.com.

.

So what is the argument against having the default contructor store a
pointer to std::terminate? This way there is no undefined behaviour,
and there is no chance that an overly cleaver compiler deduces that a
std::function must have been set to some function and then calls that
instead.
Again, I seem to be one of the few advocating against introducing more
undefined behaviour into a language that is already flooded with this
with no benefit to the end user. I am aware that UB can not be
avoided, but let us strive to reduce this as much as we can.

/Peter

On Wed, Apr 25, 2018 at 10:43 AM, Andrey Semashev
<andrey.semashev@gmail.com> wrote:
> On 04/25/18 10:24, Victor Dyachenko wrote:
>>
>> On Tuesday, April 24, 2018 at 9:19:13 PM UTC+3, Andrey Semashev wrote:
>>
>>     As Matt Calabrese said, throwing is not failing fast, crashing is. I
>>     always want my code crash ASAP if I have a bug
>>
>> So do I! But memory corruption is not immediate crash.
>
>
> I don't think memory corruption is relevant, unless you initialize
> `std::function` with a bogus pointer, from which the current check with an
> exception don't protect. I would expect the empty state to be implemented
> with a null pointer internally, calling which would result in an immediate
> crash.
>
>> Writing code in C-style - if() in each row is:
>>
>> 1) Tedious,
>
>
> Not more tedious than typing `try`/`catch` blocks.
>
>> 2) It totally water down initial algorithm, the code is mostly "write
>> only", like asm.
>
>
> Not sure what you mean here. During support and further development I modify
> both the positive code and error handling quite often.
>
> --
> 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/32262d4a-253f-6ad2-b570-e469569f71d4%40gmail.com.

--
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/CANPtknwBPSFpP-_gtuFCbfR1NKV%3DXKKX1tacmQqU0B0ZApGjjw%40mail.gmail.com.

.

--0000000000002af656056aac840b
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018, 3:38 PM Peter Koch Larsen <peter.koch.larsen@gmail.com>
wrote:

> So what is the argument against having the default contructor store a
> pointer to std::terminate?

How would that work if std::function doesn't store the same function
signature as std::terminate? This isn't different than what we have today:
a (possibly unneeded) branch, except that instead of throwing an exception,
std::terminate is called.

The argument against it is basically: I shouldn't pay for a branch that I
won't need.

This way there is no undefined behaviour,
> and there is no chance that an overly cleaver compiler deduces that a
> std::function must have been set to some function and then calls that
> instead.
> Again, I seem to be one of the few advocating against introducing more
> undefined behaviour into a language that is already flooded with this
> with no benefit to the end user.

I am aware that UB can not be
> avoided, but let us strive to reduce this as much as we can.
>
> /Peter
>
> On Wed, Apr 25, 2018 at 10:43 AM, Andrey Semashev
> <andrey.semashev@gmail.com> wrote:
> > On 04/25/18 10:24, Victor Dyachenko wrote:
> >>
> >> On Tuesday, April 24, 2018 at 9:19:13 PM UTC+3, Andrey Semashev wrote:
> >>
> >>     As Matt Calabrese said, throwing is not failing fast, crashing is. I
> >>     always want my code crash ASAP if I have a bug
> >>
> >> So do I! But memory corruption is not immediate crash.
> >
> >
> > I don't think memory corruption is relevant, unless you initialize
> > `std::function` with a bogus pointer, from which the current check with
> an
> > exception don't protect. I would expect the empty state to be implemented
> > with a null pointer internally, calling which would result in an
> immediate
> > crash.
> >
> >> Writing code in C-style - if() in each row is:
> >>
> >> 1) Tedious,
> >
> >
> > Not more tedious than typing `try`/`catch` blocks.
> >
> >> 2) It totally water down initial algorithm, the code is mostly "write
> >> only", like asm.
> >
> >
> > Not sure what you mean here. During support and further development I
> modify
> > both the positive code and error handling quite often.
> >
> > --
> > 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/32262d4a-253f-6ad2-b570-e469569f71d4%40gmail.com
> .
>
> --
> 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/CANPtknwBPSFpP-_gtuFCbfR1NKV%3DXKKX1tacmQqU0B0ZApGjjw%40mail.gmail.com
> .
>

--
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/CALmDwq27XbzL8qwurearvA5Oc132zaxYQD%2B5yEhD6d6LiZ%2B-7Q%40mail.gmail.com.

--0000000000002af656056aac840b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, =
Apr 25, 2018, 3:38 PM Peter Koch Larsen &lt;<a href=3D"mailto:peter.koch.la=
rsen@gmail.com">peter.koch.larsen@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">So what is the argument against having the default =
contructor store a<br>
pointer to std::terminate?</blockquote></div></div><div dir=3D"auto">How wo=
uld that work if std::function doesn&#39;t store the same function signatur=
e as std::terminate? This isn&#39;t different than what we have today: a (p=
ossibly unneeded) branch, except that instead of throwing an exception, std=
::terminate is called.</div><div dir=3D"auto"><br></div><div dir=3D"auto">T=
he argument against it is basically: I shouldn&#39;t pay for a branch that =
I won&#39;t need.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This way there is no u=
ndefined behaviour,<br>
and there is no chance that an overly cleaver compiler deduces that a<br>
std::function must have been set to some function and then calls that<br>
instead.<br>
Again, I seem to be one of the few advocating against introducing more<br>
undefined behaviour into a language that is already flooded with this<br>
with no benefit to the end user.</blockquote></div></div><div dir=3D"auto">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I am aware that =
UB can not be<br>
avoided, but let us strive to reduce this as much as we can.<br>
<br>
/Peter<br>
<br>
On Wed, Apr 25, 2018 at 10:43 AM, Andrey Semashev<br>
&lt;<a href=3D"mailto:andrey.semashev@gmail.com" target=3D"_blank" rel=3D"n=
oreferrer">andrey.semashev@gmail.com</a>&gt; wrote:<br>
&gt; On 04/25/18 10:24, Victor Dyachenko wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, April 24, 2018 at 9:19:13 PM UTC+3, Andrey Semashev wr=
ote:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0As Matt Calabrese said, throwing is not failing=
 fast, crashing is. I<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0always want my code crash ASAP if I have a bug<=
br>
&gt;&gt;<br>
&gt;&gt; So do I! But memory corruption is not immediate crash.<br>
&gt;<br>
&gt;<br>
&gt; I don&#39;t think memory corruption is relevant, unless you initialize=
<br>
&gt; `std::function` with a bogus pointer, from which the current check wit=
h an<br>
&gt; exception don&#39;t protect. I would expect the empty state to be impl=
emented<br>
&gt; with a null pointer internally, calling which would result in an immed=
iate<br>
&gt; crash.<br>
&gt;<br>
&gt;&gt; Writing code in C-style - if() in each row is:<br>
&gt;&gt;<br>
&gt;&gt; 1) Tedious,<br>
&gt;<br>
&gt;<br>
&gt; Not more tedious than typing `try`/`catch` blocks.<br>
&gt;<br>
&gt;&gt; 2) It totally water down initial algorithm, the code is mostly &qu=
ot;write<br>
&gt;&gt; only&quot;, like asm.<br>
&gt;<br>
&gt;<br>
&gt; Not sure what you mean here. During support and further development I =
modify<br>
&gt; both the positive code and error handling quite often.<br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" tar=
get=3D"_blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.=
<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank" rel=3D"noreferrer">std-proposals@isocpp.org</a=
>.<br>
&gt; To view this discussion on the web visit<br>
&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposal=
s/32262d4a-253f-6ad2-b570-e469569f71d4%40gmail.com" rel=3D"noreferrer noref=
errer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/32262d4a-253f-6ad2-b570-e469569f71d4%40gmail.com</a>.<br>
<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" rel=3D"noreferrer">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" rel=3D"noreferrer">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/CANPtknwBPSFpP-_gtuFCbfR1NKV%3DXKKX1t=
acmQqU0B0ZApGjjw%40mail.gmail.com" rel=3D"noreferrer noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtk=
nwBPSFpP-_gtuFCbfR1NKV%3DXKKX1tacmQqU0B0ZApGjjw%40mail.gmail.com</a>.<br>
</blockquote></div></div></div>

<p></p>

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

--0000000000002af656056aac840b--

.

On 04/25/18 16:37, Peter Koch Larsen wrote:
> So what is the argument against having the default contructor store a
> pointer to std::terminate?

The same argument there is against storing a pointer to function that
throws `std::bad_function_call` - it becomes difficult to test if
`std::function` is in an empty state in some configurations.

It looks like having an additional `bool is_empty` member inside
`std::function` would solve this problem, although it would add to the
object size.

--
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/afffbbd6-9512-11e3-4052-2196e602d192%40gmail.com.

.

--000000000000d31cb5056aacafbf
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 25, 2018, 09:38 Peter Koch Larsen <peter.koch.larsen@gmail.com>
wrote:

> So what is the argument against having the default contructor store a
> pointer to std::terminate? This way there is no undefined behaviour,
> and there is no chance that an overly cleaver compiler deduces that a
> std::function must have been set to some function and then calls that
> instead.
> Again, I seem to be one of the few advocating against introducing more
> undefined behaviour into a language that is already flooded with this
> with no benefit to the end user. I am aware that UB can not be
> avoided, but let us strive to reduce this as much as we can.
>

I'd rather we just rely on the (upcoming) contracts language feature so
that people have control over what happens on a detected contract
violation. It's less to specify, more powerful, and avoids picking a form
of "handling" of the error that a user may not want. For example -- I would
personally usually want either some form of termination, or nothing (UB),
however I wouldn't ever want it to call std::terminate. I would want to
call either std::quick_exit or maybe std::abort, etc.. Until that point,
I'd prefer it if we just kept our contracts narrow. We can always widen
them later if we start narrow, but it's harder to narrow them later if we
start wide.

--
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/CANh8DEkOfxNmyc1-c9H%2BL0zNSBt5e8krTfE%3DT%2BwyVhaW_WUEYw%40mail.gmail.com.

--000000000000d31cb5056aacafbf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Wed, Apr 25, 2018, 09:38 Peter Koch Larsen &lt;<a href=3D"mailt=
o:peter.koch.larsen@gmail.com" target=3D"_blank">peter.koch.larsen@gmail.co=
m</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So what is the arg=
ument against having the default contructor store a<br>
pointer to std::terminate? This way there is no undefined behaviour,<br>
and there is no chance that an overly cleaver compiler deduces that a<br>
std::function must have been set to some function and then calls that<br>
instead.<br>
Again, I seem to be one of the few advocating against introducing more<br>
undefined behaviour into a language that is already flooded with this<br>
with no benefit to the end user. I am aware that UB can not be<br>
avoided, but let us strive to reduce this as much as we can.<br></blockquot=
e></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;d rather =
we just rely on the (upcoming) contracts language feature so that people ha=
ve control over what happens on a detected contract violation. It&#39;s les=
s to specify, more powerful, and avoids picking a form of &quot;handling&qu=
ot; of the error that a user may not want. For example -- I would personall=
y usually want either some form of termination, or nothing (UB), however I =
wouldn&#39;t ever want it to call std::terminate. I would want to call eith=
er std::quick_exit or maybe std::abort, etc.. Until that point, I&#39;d pre=
fer it if we just kept our contracts narrow. We can always widen them later=
 if we start narrow, but it&#39;s harder to narrow them later if we start w=
ide.</div></div></div>

<p></p>

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

--000000000000d31cb5056aacafbf--

.

On 04/25/18 16:47, Nicolas Lesser wrote:
> On Wed, Apr 25, 2018, 3:38 PM Peter Koch Larsen
> <peter.koch.larsen@gmail.com <mailto:peter.koch.larsen@gmail.com>> wrote:
>
>     So what is the argument against having the default contructor store a
>     pointer to std::terminate?
>
> How would that work if std::function doesn't store the same function
> signature as std::terminate?

This depends on the ABI, of course, but you usually can call a function
with a different signature by casting the function pointer. There are
restrictions, of course. The calling convention should match, the
function should not access its arguments and the return type should be
binary compatible, and probably more. But all of this doesn't really
matter when the function is `std::abort` or `std::terminate`, which will
not return and doesn't have any arguments.

This is all UB from the language perspective, but the standard library
implementers have a license to break rules sometimes.

--
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/f2ad878b-e4eb-2e74-4c72-dea2903be2f6%40gmail.com.

.

--001a11415f0c08495b056aacc7ff
Content-Type: text/plain; charset="UTF-8"

This is not rocket science, you can always wrap the call to std::terminate
into a generic thing that'll be then used with the correct signature.
That's not a problem.

On Wed, Apr 25, 2018 at 4:05 PM Andrey Semashev <andrey.semashev@gmail.com>
wrote:

> On 04/25/18 16:47, Nicolas Lesser wrote:
> > On Wed, Apr 25, 2018, 3:38 PM Peter Koch Larsen
> > <peter.koch.larsen@gmail.com <mailto:peter.koch.larsen@gmail.com>>
> wrote:
> >
> >     So what is the argument against having the default contructor store a
> >     pointer to std::terminate?
> >
> > How would that work if std::function doesn't store the same function
> > signature as std::terminate?
>
> This depends on the ABI, of course, but you usually can call a function
> with a different signature by casting the function pointer. There are
> restrictions, of course. The calling convention should match, the
> function should not access its arguments and the return type should be
> binary compatible, and probably more. But all of this doesn't really
> matter when the function is `std::abort` or `std::terminate`, which will
> not return and doesn't have any arguments.
>
> This is all UB from the language perspective, but the standard library
> implementers have a license to break rules sometimes.
>
> --
> 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/f2ad878b-e4eb-2e74-4c72-dea2903be2f6%40gmail.com
> .
>

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

--001a11415f0c08495b056aacc7ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is not rocket science, you can always wrap the call t=
o std::terminate into a generic thing that&#39;ll be then used with the cor=
rect signature. That&#39;s not a problem.</div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Wed, Apr 25, 2018 at 4:05 PM Andrey Semashev &lt;<a =
href=3D"mailto:andrey.semashev@gmail.com">andrey.semashev@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">On 04/25/18 16:47, Nicolas =
Lesser wrote:<br>
&gt; On Wed, Apr 25, 2018, 3:38 PM Peter Koch Larsen <br>
&gt; &lt;<a href=3D"mailto:peter.koch.larsen@gmail.com" target=3D"_blank">p=
eter.koch.larsen@gmail.com</a> &lt;mailto:<a href=3D"mailto:peter.koch.lars=
en@gmail.com" target=3D"_blank">peter.koch.larsen@gmail.com</a>&gt;&gt; wro=
te:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0So what is the argument against having the default =
contructor store a<br>
&gt;=C2=A0 =C2=A0 =C2=A0pointer to std::terminate?<br>
&gt; <br>
&gt; How would that work if std::function doesn&#39;t store the same functi=
on <br>
&gt; signature as std::terminate?<br>
<br>
This depends on the ABI, of course, but you usually can call a function <br=
>
with a different signature by casting the function pointer. There are <br>
restrictions, of course. The calling convention should match, the <br>
function should not access its arguments and the return type should be <br>
binary compatible, and probably more. But all of this doesn&#39;t really <b=
r>
matter when the function is `std::abort` or `std::terminate`, which will <b=
r>
not return and doesn&#39;t have any arguments.<br>
<br>
This is all UB from the language perspective, but the standard library <br>
implementers have a license to break rules sometimes.<br>
<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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f2ad878b-e4eb-2e74-4c72-dea2903be2f6%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/f2ad878b-e4eb-2e74-4c72-dea2903be2f6%40=
gmail.com</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQvEOK5Oxkd_5csrpP1nH0MrX6f5mCH=
BW%3DNc6zotegR0A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQvEOK5Ox=
kd_5csrpP1nH0MrX6f5mCHBW%3DNc6zotegR0A%40mail.gmail.com</a>.<br />

--001a11415f0c08495b056aacc7ff--

.

On 04/25/18 17:06, Micha=C5=82 Dominiak wrote:
> This is not rocket science, you can always wrap the call to=20
> std::terminate into a generic thing that'll be then used with the=20
> correct signature. That's not a problem.

True.

> On Wed, Apr 25, 2018 at 4:05 PM Andrey Semashev=20
> <andrey.semashev@gmail.com <mailto:andrey.semashev@gmail.com>> wrote:
>=20
>     On 04/25/18 16:47, Nicolas Lesser wrote:
>      > On Wed, Apr 25, 2018, 3:38 PM Peter Koch Larsen
>      > <peter.koch.larsen@gmail.com <mailto:peter.koch.larsen@gmail.com>
>     <mailto:peter.koch.larsen@gmail.com
>     <mailto:peter.koch.larsen@gmail.com>>> wrote:
>      >
>      >=C2=A0 =C2=A0 =C2=A0So what is the argument against having the defa=
ult contructor
>     store a
>      >=C2=A0 =C2=A0 =C2=A0pointer to std::terminate?
>      >
>      > How would that work if std::function doesn't store the same functi=
on
>      > signature as std::terminate?
>=20
>     This depends on the ABI, of course, but you usually can call a functi=
on
>     with a different signature by casting the function pointer. There are
>     restrictions, of course. The calling convention should match, the
>     function should not access its arguments and the return type should b=
e
>     binary compatible, and probably more. But all of this doesn't really
>     matter when the function is `std::abort` or `std::terminate`, which
>     will
>     not return and doesn't have any arguments.
>=20
>     This is all UB from the language perspective, but the standard librar=
y
>     implementers have a license to break rules sometimes.
>=20
>     --=20
>     You received this message because you are subscribed to the Google
>     Groups "ISO C++ Standard - Future Proposals" group.
>     To unsubscribe from this group and stop receiving emails from it,
>     send an email to std-proposals+unsubscribe@isocpp.org
>     <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
>     To post to this group, send email to std-proposals@isocpp.org
>     <mailto:std-proposals@isocpp.org>.
>     To view this discussion on the web visit
>     https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2ad878b=
-e4eb-2e74-4c72-dea2903be2f6%40gmail.com.
>=20
> --=20
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQvEOK=
5Oxkd_5csrpP1nH0MrX6f5mCHBW%3DNc6zotegR0A%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQvEO=
K5Oxkd_5csrpP1nH0MrX6f5mCHBW%3DNc6zotegR0A%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d42f29c9-0dac-de1b-ce7f-760473d82214%40gmail.com=
..

.

 Why is this so? Why can't you compare the function to std::terminate
and return true if they are equal.
I am aware that you can not compare two std::functions for equality,
but this is library code and I believe that this case could be easily
solved without any overhead.

/Peter

On Wed, Apr 25, 2018 at 3:58 PM, Andrey Semashev
<andrey.semashev@gmail.com> wrote:
> On 04/25/18 16:37, Peter Koch Larsen wrote:
>>
>> So what is the argument against having the default contructor store a
>> pointer to std::terminate?
>
>
> The same argument there is against storing a pointer to function that throws
> `std::bad_function_call` - it becomes difficult to test if `std::function`
> is in an empty state in some configurations.
>
> It looks like having an additional `bool is_empty` member inside
> `std::function` would solve this problem, although it would add to the
> object size.
>
> --
> 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/afffbbd6-9512-11e3-4052-2196e602d192%40gmail.com.

--
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/CANPtknzjB3oFHbqyMX415QWkBTAzPBrq%3D4LQ786b5y71Ous-vA%40mail.gmail.com.

.

On 04/25/18 17:21, Peter Koch Larsen wrote:
> On Wed, Apr 25, 2018 at 3:58 PM, Andrey Semashev
> <andrey.semashev@gmail.com> wrote:
>> On 04/25/18 16:37, Peter Koch Larsen wrote:
>>>
>>> So what is the argument against having the default contructor store a
>>> pointer to std::terminate?
>>
>>
>> The same argument there is against storing a pointer to function that throws
>> `std::bad_function_call` - it becomes difficult to test if `std::function`
>> is in an empty state in some configurations.
>>
>   Why is this so? Why can't you compare the function to std::terminate
> and return true if they are equal.

Because the user's code can be linked statically to the standard
library, and yet consist of multiple shared objects. There would be
multiple copies of `std::terminate` in the process.

--
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/197edc0b-2d09-fa9f-d15b-361e1797f566%40gmail.com.

.

--000000000000e9a830056aad3f50
Content-Type: text/plain; charset="UTF-8"

On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:

> Also, it will only get into that state because some move-operation threw.
>

*cough*

libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST

--
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/CANh8DEk3nWNHEi842MPq6AE4o%3DLaOWOOze5XE3VJCatBU9s%3DkQ%40mail.gmail.com.

--000000000000e9a830056aad3f50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Apr 24=
, 2018 at 1:32 PM Tony V E &lt;<a href=3D"mailto:tvaneerd@gmail.com">tvanee=
rd@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Also, it will only =
get into that state because some move-operation threw.</div></div></blockqu=
ote><div><br></div><div>*cough*=C2=A0</div><div><br></div><div>libc++: <a h=
ref=3D"https://wandbox.org/permlink/0ag3V2oVa3MBcWmz">https://wandbox.org/p=
ermlink/0ag3V2oVa3MBcWmz</a></div><div>libstdc++:=C2=A0<a href=3D"https://w=
andbox.org/permlink/LEUsrj9ir5vyVcST">https://wandbox.org/permlink/LEUsrj9i=
r5vyVcST</a></div></div></div>

<p></p>

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

--000000000000e9a830056aad3f50--

.

I explicitly proposed to make std::function weakly customizable so
that you could keep undefined behaviour if you were one of the true
believers in that aspect of C++. That proposal was rejected heavily.
For your proposal regarding using contracts, I am unsure if this is a
feasible way forward. With my limited knowledge, I would expect that
the effect of contracts would be configurable on a system-wide level,
not per class. My wish would be that any feature of C++ should ideally
work out of the box, requiring explicit coding (or compiler flags) to
do the unexpected. And by "work", I include those cases where the
programmer inadvertently misuses the feature.

On Wed, Apr 25, 2018 at 3:59 PM, 'Matt Calabrese' via ISO C++ Standard
- Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Apr 25, 2018, 09:38 Peter Koch Larsen <peter.koch.larsen@gmail.com>
> wrote:
>>
>> So what is the argument against having the default contructor store a
>> pointer to std::terminate? This way there is no undefined behaviour,
>> and there is no chance that an overly cleaver compiler deduces that a
>> std::function must have been set to some function and then calls that
>> instead.
>> Again, I seem to be one of the few advocating against introducing more
>> undefined behaviour into a language that is already flooded with this
>> with no benefit to the end user. I am aware that UB can not be
>> avoided, but let us strive to reduce this as much as we can.
>
>
> I'd rather we just rely on the (upcoming) contracts language feature so that
> people have control over what happens on a detected contract violation. It's
> less to specify, more powerful, and avoids picking a form of "handling" of
> the error that a user may not want. For example -- I would personally
> usually want either some form of termination, or nothing (UB), however I
> wouldn't ever want it to call std::terminate. I would want to call either
> std::quick_exit or maybe std::abort, etc.. Until that point, I'd prefer it
> if we just kept our contracts narrow. We can always widen them later if we
> start narrow, but it's harder to narrow them later if we start wide.
>
> --
> 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/CANh8DEkOfxNmyc1-c9H%2BL0zNSBt5e8krTfE%3DT%2BwyVhaW_WUEYw%40mail.gmail.com.

--
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/CANPtknw3%2BicRhU5g1osMC25d4XNu0BLwKE16G__sRCGY%2B%2B2OVQ%40mail.gmail.com.

.

On 2018-04-24 11:47, Richard Hodges wrote:
[...]
> IMHO there is way too much obsession in these channels about the
> =E2=80=9Ccost=E2=80=9D of exceptions.

"Unfortunately", C++ (unlike Java, though _some_ people try) is used=20
(and usable) in hard-real-time environments. The "cost of exceptions"=20
there, as with dynamic memory allocation, is unpredictable execution=20
times. _That_ is what makes them unacceptable for SG14. And this is why=20
throwing exceptions for "safety" locks out the very client=C3=A8le that is=
=20
mongst those that would benefit the most from more secure programming.

And this is not about exceptions, actually. I would raise my eyebrow=20
also if function::operator() returned std::expected. It's about narrow=20
vs. wide contracts and that the former are perfectly ok.

And yes, I don't want the check to have to be in every iteration of

     if (function &f =3D ...)
         for (auto &&e : collection)
             f(e);

just because the compiler can't prove that 'f' does not get modified=20
under iteration. This is why narrow contracts are better: it puts (or:=20
will eventually put) the decision of what should happen on precondition=20
violation in the hands of the end-developer, where it belongs. A wide=20
contract nails this decision for everyone, whether it works for them or=20
not.

Thanks,
Marc

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b11f922657d25895a2abd42576a80c9f%40kdab.com.

.

On 25 April 2018 at 17:40, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com> wrote:
>>
>> Also, it will only get into that state because some move-operation threw.
>
>
> *cough*
>
> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz
> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST


You might want to entertain adding that test to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517.
I think I'll fix that bug.

--
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/CAFk2RUbO5WSx%2BCk6_q32%2BDRFJHRUxGB%2BGgzAGfBDUNqb%3D9BdAg%40mail.gmail.com.

.

------=_Part_2073_1187518735.1524699264541
Content-Type: multipart/alternative;
 boundary="----=_Part_2074_1691077912.1524699264542"

------=_Part_2074_1691077912.1524699264542
Content-Type: text/plain; charset="UTF-8"



On Wednesday, April 25, 2018 at 4:25:05 PM UTC+2, Andrey Semashev wrote:
>
> On 04/25/18 17:21, Peter Koch Larsen wrote:
> > On Wed, Apr 25, 2018 at 3:58 PM, Andrey Semashev
> > <andrey....@gmail.com <javascript:>> wrote:
> >> On 04/25/18 16:37, Peter Koch Larsen wrote:
> >>>
> >>> So what is the argument against having the default contructor store a
> >>> pointer to std::terminate?
> >>
> >>
> >> The same argument there is against storing a pointer to function that
> throws
> >> `std::bad_function_call` - it becomes difficult to test if
> `std::function`
> >> is in an empty state in some configurations.
> >>
> >   Why is this so? Why can't you compare the function to std::terminate
> > and return true if they are equal.
>
> Because the user's code can be linked statically to the standard
> library, and yet consist of multiple shared objects. There would be
> multiple copies of `std::terminate` in the process.
>

One way around is using invalid pointer values to store additional data, if
function pointer can be only alignment to 2bytes than you can reuse last
bit to store more information.
It will have small overhead but is doable (AFAIK clang use extensively
similar tricks).

--
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/d07d7cd3-6c7a-4fc6-ba72-665d43badbdb%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, April 25, 2018 at 4:25:05 PM UTC+2, =
Andrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 04/25=
/18 17:21, Peter Koch Larsen wrote:
<br>&gt; On Wed, Apr 25, 2018 at 3:58 PM, Andrey Semashev
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"sMu_G2pFBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">andrey....@gmail.com</a>&gt; wrote:
<br>&gt;&gt; On 04/25/18 16:37, Peter Koch Larsen wrote:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; So what is the argument against having the default contruc=
tor store a
<br>&gt;&gt;&gt; pointer to std::terminate?
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; The same argument there is against storing a pointer to functi=
on that throws
<br>&gt;&gt; `std::bad_function_call` - it becomes difficult to test if `st=
d::function`
<br>&gt;&gt; is in an empty state in some configurations.
<br>&gt;&gt;
<br>&gt; =C2=A0 Why is this so? Why can&#39;t you compare the function to s=
td::terminate
<br>&gt; and return true if they are equal.
<br>
<br>Because the user&#39;s code can be linked statically to the standard=20
<br>library, and yet consist of multiple shared objects. There would be=20
<br>multiple copies of `std::terminate` in the process.
<br></blockquote><div><br>One way around is using invalid pointer values to=
 store additional data, if function pointer can be only alignment to 2bytes=
 than you can reuse last bit to store more information.<br>It will have sma=
ll overhead but is doable (AFAIK clang use extensively similar tricks).<br>=
</div></div>

<p></p>

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

------=_Part_2074_1691077912.1524699264542--

------=_Part_2073_1187518735.1524699264541--

.

On 04/26/18 02:34, inkwizytoryankes@gmail.com wrote:
>=20
>=20
> On Wednesday, April 25, 2018 at 4:25:05 PM UTC+2, Andrey Semashev wrote:
>=20
>     On 04/25/18 17:21, Peter Koch Larsen wrote:
>      > On Wed, Apr 25, 2018 at 3:58 PM, Andrey Semashev
>      > <andrey....@gmail.com> wrote:
>      >> On 04/25/18 16:37, Peter Koch Larsen wrote:
>      >>>
>      >>> So what is the argument against having the default contructor
>     store a
>      >>> pointer to std::terminate?
>      >>
>      >>
>      >> The same argument there is against storing a pointer to function
>     that throws
>      >> `std::bad_function_call` - it becomes difficult to test if
>     `std::function`
>      >> is in an empty state in some configurations.
>      >>
>      > =C2=A0 Why is this so? Why can't you compare the function to
>     std::terminate
>      > and return true if they are equal.
>=20
>     Because the user's code can be linked statically to the standard
>     library, and yet consist of multiple shared objects. There would be
>     multiple copies of `std::terminate` in the process.
>=20
> One way around is using invalid pointer values to store additional data,=
=20
> if function pointer can be only alignment to 2bytes than you can reuse=20
> last bit to store more information.
> It will have small overhead but is doable (AFAIK clang use extensively=20
> similar tricks).

Mixing bits into pointers is a known tactics, but you'd have to be=20
clearing those bits on every call, which kind of negates the win from=20
avoiding the test for being empty.

BTW, pointers to code may not have a guaranteed minimum alignment, so=20
mixing additional data into those can be difficult.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/419b72bb-4211-8bb9-557c-3b8304fcb565%40gmail.com=
..

.