Topic: About expected<T, E, Traits=error_traits<E>>
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 21:01:14 +0100
Raw View
This is a multi-part message in MIME format.
--------------090909010608060702070306
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
I would like to re-raise the expected discussion. Beside the conflicting
part "managing errors in a different way", that should be covered by a
specific paper, I would like to open the discussion in order to have a
better proposal for expected.
There were some concerns about the exception throw when there is no
value. I'm wondering if we can do as for basic_string, we can have an
error_traits that define which exception is thrown and that can also do
conversion from exception to errors.
basic_expected<T, Error=exception _ptr, Traits=error_traits<Error>>
we could have a specialization for error_code/error_condition that would
throw a system_error.
What do you think of this customization?
Vicente
template <class Error>
struct error_traits {
template <class Exception>
static Error make_error(Exception const&) {
return Error{};
}
static Error make_error_from_current_exception() {
return Error{};
}
static void rethrow(Error const& e) {
throw e; // throw Error by default
// throw bad_access<Error>{e}; // or bad_access if preferred
}
};
template <>
struct error_traits<std::exception_ptr> {
template <class Exception>
static std::exception_ptr make_error(Exception const&e) {
return std::make_exception_ptr(e);
}
static std::exception_ptr make_error_from_current_exception() {
return std::current_exception();
}
static void rethrow(std::exception_ptr const& e) {
std::rethrow_exception(e);
}
};
template <>
struct error_traits<std::error_code> {
template <class Exception>
static std::error_code make_error(std::system_error const&e) {
return e.code();
}
template <class Exception>
// requires is_base_of<std::system_error, Exception>
static std::error_code make_error(Exception const&e) {
return e.code();
}
static std::error_code make_error_from_current_exception() {
try {
throw;
} catch (std::system_error & e) {
return make_error(e);
} catch (...) {
return std::error_code();
}
}
static void rethrow(std::error_code const& e) {
throw std::system_error(e);
}
};
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--------------090909010608060702070306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the
conflicting part "managing errors in a different way", that should
be covered by a specific paper, I would like to open the
discussion in order to have a better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is
no value. I'm wondering if we can do as for basic_string, we can
have an error_traits that define which exception is thrown and
that can also do conversion from exception to errors.<br>
<br>
basic_expected<T, Error=3Dexception _ptr,
Traits=3Derror_traits<Error>><br>
<br>
we could have a specialization for error_code/error_condition that
would throw a system_error.<br>
<br>
What do you think of this customization?<br>
<br>
Vicente<br>
<br>
<br>
=C2=A0 template <class Error><br>
=C2=A0 struct error_traits=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0 template <class Exception><br>
=C2=A0=C2=A0=C2=A0 static Error make_error(Exception const&)=C2=
=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return Error{};<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 static Error make_error_from_current_exception()=
=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return Error{};<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 static void rethrow(Error const& e)=C2=A0=C2=
=A0=C2=A0 {<br>
</font><font size=3D"+1"><font size=3D"+1"><font size=3D"+1">=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 throw
e; // throw Error by default<br>
</font></font></font><font size=3D"+1"><font size=3D"+1"><font
size=3D"+1">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // throw bad_access<=
;Error>{e}; // or
bad_access if preferred<br>
</font></font>=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0 };<br>
<br>
=C2=A0 template <><br>
=C2=A0 struct error_traits<std::exception_ptr>=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0 template <class Exception><br>
=C2=A0=C2=A0=C2=A0 static std::exception_ptr make_error(Exception con=
st&e)=C2=A0=C2=A0=C2=A0
{<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std::make_exception_ptr(e);<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 static std::exception_ptr
make_error_from_current_exception()=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std::current_exception();<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 static void rethrow(std::exception_ptr const& =
e)=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::rethrow_exception(e);<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0 };<br>
<br>
=C2=A0 template <><br>
=C2=A0 struct error_traits<std::error_code>=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0 template <class Exception><br>
=C2=A0=C2=A0=C2=A0 static std::error_code make_error(std::system_erro=
r
const&e)=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return e.code();<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 template <class Exception><br>
=C2=A0=C2=A0=C2=A0 // requires is_base_of<std::system_error, Excep=
tion><br>
=C2=A0=C2=A0=C2=A0 static std::error_code make_error(Exception const&=
amp;e)=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return e.code();<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 static std::error_code make_error_from_current_exc=
eption()=C2=A0=C2=A0=C2=A0
{<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 try {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 throw;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } catch (std::system_error & e) {<=
br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return make_error(e);<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } catch (...) {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return std::error_code();<=
br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0=C2=A0=C2=A0 static void rethrow(std::error_code const& e)=
=C2=A0=C2=A0=C2=A0 {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 throw std::system_error(e);<br>
=C2=A0=C2=A0=C2=A0 }<br>
=C2=A0 };<br>
<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------090909010608060702070306--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 11 Nov 2015 12:29:05 -0800 (PST)
Raw View
------=_Part_746_1583806667.1447273745949
Content-Type: multipart/alternative;
boundary="----=_Part_747_2068656736.1447273745949"
------=_Part_747_2068656736.1447273745949
Content-Type: text/plain; charset=UTF-8
On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet
Escriba wrote:
>
> Hi,
>
> I would like to re-raise the expected discussion. Beside the conflicting
> part "managing errors in a different way", that should be covered by a
> specific paper, I would like to open the discussion in order to have a
> better proposal for expected.
>
> There were some concerns about the exception throw when there is no value.
> I'm wondering if we can do as for basic_string, we can have an error_traits
> that define which exception is thrown and that can also do conversion from
> exception to errors.
>
Here's my feeling on this.
If you have some expected object and you do `.value` on it (or any of its
equivalents), what you are saying very clearly is this: I fully and
completely expect that this object will not be in the error state. That's
the conceptual precondition of your code.
If that condition is violated, then the problem with your code is that the
condition was violated. That is, the problem with your code is not that a
function emitted an error of some type. It's that a function emitted an
error and *you didn't check it*. This is the same error no matter what the
error code type is, so it should throw the same exception from every
`expected` object.
That being said, I could see having a `throw_if_error` function, which will
throw an exception based on the error code if the expected object is in the
error state.
Also, we don't want to overburden `expected` with customization machinery.
Not unless there's a really good reason. I don't want to have to hunt down
some traits class to see what I should have to catch. Throwing the error
code type itself, whatever that type is, should be sufficient for a
function like `throw_if_error`.
After all, I've always felt that the point of `expected` was to *not* use
exceptions, to have an alternative to them. It seems kinda silly to add a
customization point solely for exception behavior, when that's exactly what
you're trying to avoid.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_747_2068656736.1447273745949
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, November 11, 2015 at 3:01:19 PM UTC-=
5, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the
conflicting part "managing errors in a different way", that=
should
be covered by a specific paper, I would like to open the
discussion in order to have a better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is
no value. I'm wondering if we can do as for basic_string, we can
have an error_traits that define which exception is thrown and
that can also do conversion from exception to errors.<br></font></div=
></blockquote><div><br>Here's my feeling on this.<br><br>If you have so=
me expected object and you do `.value` on it (or any of its equivalents), w=
hat you are saying very clearly is this: I fully and completely expect that=
this object will not be in the error state. That's the conceptual prec=
ondition of your code.<br><br>If that condition is violated, then the probl=
em with your code is that the condition was violated. That is, the problem =
with your code is not that a function emitted an error of some type. It'=
;s that a function emitted an error and <i>you didn't check it</i>. Thi=
s is the same error no matter what the error code type is, so it should thr=
ow the same exception from every `expected` object.<br><br>That being said,=
I could see having a `throw_if_error` function, which will throw an except=
ion based on the error code if the expected object is in the error state.<b=
r><br>Also, we don't want to overburden `expected` with customization m=
achinery. Not unless there's a really good reason. I don't want to =
have to hunt down some traits class to see what I should have to catch. Thr=
owing the error code type itself, whatever that type is, should be sufficie=
nt for a function like `throw_if_error`.<br><br>After all, I've always =
felt that the point of `expected` was to <i>not</i> use exceptions, to have=
an alternative to them. It seems kinda silly to add a customization point =
solely for exception behavior, when that's exactly what you're tryi=
ng to avoid.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_747_2068656736.1447273745949--
------=_Part_746_1583806667.1447273745949--
.
Author: Nevin Liber <nevin@cplusplusguy.com>
Date: Wed, 11 Nov 2015 14:37:13 -0600
Raw View
--94eb2c0329c4f38580052449ccea
Content-Type: text/plain; charset=UTF-8
On 11 November 2015 at 14:01, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> There were some concerns about the exception throw when there is no value.
> I'm wondering if we can do as for basic_string, we can have an error_traits
> that define which exception is thrown and that can also do conversion from
> exception to errors.'
>
I'm not a fan of traits classes. They complicate interfaces to the point
that virtually no one actually uses anything but the defaults.
Let's take basic_string as the example. Other than standard library
implementors testing their code, is there a string class out there in the
wild whose only difference is a different traits class?
Or you can take allocators as an example, which get more and more
complicated with every revision of the standard and have gotten to the
point that they infest classes that *never* do allocation (such as
std::tuple) as well embarrassingly require support for them into classes
that have no known way of being implemented (such as std::function and
std::experimental::any, although we may be able to rescue that when have
polymorphic allocator support in the standard).
Instead of offering maximum flexibility, we should be making the hard
choices (and they are hard) on what the right behavior is for the majority
of users. The experts that need different behavior, being experts, can
write and use their own classes.
IMNSHO, of course...
--
Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--94eb2c0329c4f38580052449ccea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 November 2015 at 14:01, Vicente J. Botet Escriba <sp=
an dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_b=
lank">vicente.botet@wanadoo.fr</a>></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">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><font size=3D"+1">There were so=
me concerns about the exception throw when there is
no value. I'm wondering if we can do as for basic_string, we can
have an error_traits that define which exception is thrown and
that can also do conversion from exception to errors.'<br></font>=
</div></blockquote><div><br></div><div>I'm not a fan of traits classes.=
=C2=A0 They complicate interfaces to the point that virtually no one actual=
ly uses anything but the defaults.</div><div><br></div><div>Let's take =
basic_string as the example.=C2=A0 Other than standard library implementors=
testing their code, is there a string class out there in the wild whose on=
ly difference is a different traits class?</div><div><br></div><div>Or you =
can take allocators as an example, which get more and more complicated with=
every revision of the standard and have gotten to the point that they infe=
st classes that=C2=A0<i>never</i>=C2=A0do allocation (such as std::tuple) a=
s well embarrassingly require support for them into classes that have no kn=
own way of being implemented (such as std::function and std::experimental::=
any, although we may be able to rescue that when have polymorphic allocator=
support in the standard).</div><div><br></div><div>Instead of offering max=
imum flexibility, we should be making the hard choices (and they are hard) =
on what the right behavior is for the majority of users.=C2=A0 The experts =
that need different behavior, being experts, can write and use their own cl=
asses.</div><div><br></div><div>IMNSHO, of course...<br>-- <br><div><div di=
r=3D"ltr">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@cplusplusguy.com</a>>=
;=C2=A0 <a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"=
_blank">+1-847-691-1404</a><br></div></div>
</div></div></div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--94eb2c0329c4f38580052449ccea--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 15:52:19 -0500
Raw View
--001a11c377a29b24f305244a0083
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 3:37 PM, Nevin Liber <nevin@cplusplusguy.com> wrote:
> On 11 November 2015 at 14:01, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> There were some concerns about the exception throw when there is no
>> value. I'm wondering if we can do as for basic_string, we can have an
>> error_traits that define which exception is thrown and that can also do
>> conversion from exception to errors.'
>>
>
> I'm not a fan of traits classes. They complicate interfaces to the point
> that virtually no one actually uses anything but the defaults.
>
> Let's take basic_string as the example. Other than standard library
> implementors testing their code, is there a string class out there in the
> wild whose only difference is a different traits class?
>
> Or you can take allocators as an example, which get more and more
> complicated with every revision of the standard and have gotten to the
> point that they infest classes that *never* do allocation (such as
> std::tuple) as well embarrassingly require support for them into classes
> that have no known way of being implemented (such as std::function and
> std::experimental::any, although we may be able to rescue that when have
> polymorphic allocator support in the standard).
>
> Instead of offering maximum flexibility, we should be making the hard
> choices (and they are hard) on what the right behavior is for the majority
> of users. The experts that need different behavior, being experts, can
> write and use their own classes.
>
> IMNSHO, of course...
> --
> Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com
> <nevin@eviloverlord.com>> +1-847-691-1404
>
> --
>
I'm not disagreeing, but the other example is vector<bool>. (Allocators,
vector<bool>, iostreams - things to be unfavourably compared to).
ie I was unsure about expected<T, E> working differently when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an exception.
But we could define "is an exception" to be "derived from std::exception".
Or is exception_ptr. Or...
On the other hand, I kind of agree that if E is an exception, the user
probably expects it to be thrown if they call value() and the value is not
there.
Vicente, what are all the differences, in the most recent proposal, between
handling exceptions vs errors?
ie where/when/how would these traits be called?
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c377a29b24f305244a0083
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 Wed, Nov 11, 2015 at 3:37 PM, Nevin Liber <span dir=3D"ltr"><<a h=
ref=3D"mailto:nevin@cplusplusguy.com" target=3D"_blank">nevin@cplusplusguy.=
com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
">On 11 November 2015 at 14:01, Vicente J. Botet Escriba <span dir=3D"ltr">=
<<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.b=
otet@wanadoo.fr</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><font size=3D"+1">There were so=
me concerns about the exception throw when there is
no value. I'm wondering if we can do as for basic_string, we can
have an error_traits that define which exception is thrown and
that can also do conversion from exception to errors.'<br></font>=
</div></blockquote><div><br></div><div>I'm not a fan of traits classes.=
=C2=A0 They complicate interfaces to the point that virtually no one actual=
ly uses anything but the defaults.</div><div><br></div><div>Let's take =
basic_string as the example.=C2=A0 Other than standard library implementors=
testing their code, is there a string class out there in the wild whose on=
ly difference is a different traits class?</div><div><br></div><div>Or you =
can take allocators as an example, which get more and more complicated with=
every revision of the standard and have gotten to the point that they infe=
st classes that=C2=A0<i>never</i>=C2=A0do allocation (such as std::tuple) a=
s well embarrassingly require support for them into classes that have no kn=
own way of being implemented (such as std::function and std::experimental::=
any, although we may be able to rescue that when have polymorphic allocator=
support in the standard).</div><div><br></div><div>Instead of offering max=
imum flexibility, we should be making the hard choices (and they are hard) =
on what the right behavior is for the majority of users.=C2=A0 The experts =
that need different behavior, being experts, can write and use their own cl=
asses.</div><div><br></div><div>IMNSHO, of course...<span class=3D"HOEnZb">=
<font color=3D"#888888"><br>-- <br><div><div dir=3D"ltr">=C2=A0Nevin "=
:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@cplusplusguy.com</a>>=C2=A0 <a href=3D"tel:%2B1-=
847-691-1404" value=3D"+18476911404" target=3D"_blank">+1-847-691-1404</a><=
br></div></div>
</font></span></div></div></div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br></div></div></blockquote><div><br></div></div>I'm not disagreein=
g, but the other example is vector<bool>.=C2=A0 (Allocators, vector&l=
t;bool>, iostreams - things to be unfavourably compared to).<br><br></di=
v><div class=3D"gmail_extra">ie I was unsure about expected<T, E> wor=
king differently when E is an exception, vs when E is an int or any other e=
rror.<br></div><div class=3D"gmail_extra">Particularly since in C++, almost=
anything can be thrown as an exception.=C2=A0 But we could define "is=
an exception" to be "derived from std::exception".=C2=A0 Or=
is exception_ptr. Or...<br><br></div><div class=3D"gmail_extra">On the oth=
er hand, I kind of agree that if E is an exception, the user probably expec=
ts it to be thrown if they call value() and the value is not there.<br><br>=
</div><div class=3D"gmail_extra">Vicente, what are all the differences, in =
the most recent proposal, between handling exceptions vs errors?<br></div><=
div class=3D"gmail_extra">ie where/when/how would these traits be called?<b=
r><br></div><div class=3D"gmail_extra">Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c377a29b24f305244a0083--
.
Author: Nevin Liber <nevin@cplusplusguy.com>
Date: Wed, 11 Nov 2015 15:00:04 -0600
Raw View
--001a1141e256acf12105244a1e24
Content-Type: text/plain; charset=UTF-8
On 11 November 2015 at 14:52, Tony V E <tvaneerd@gmail.com> wrote:
>
> I'm not disagreeing, but the other example is vector<bool>. (Allocators,
> vector<bool>, iostreams - things to be unfavourably compared to).
>
> ie I was unsure about expected<T, E> working differently when E is an
> exception, vs when E is an int or any other error.
>
I'm not suggesting that either; we shouldn't have different behavior based
on the type of E.
If we want different behavior, we should either have two differently named
functions or two differently named classes.
--
Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1141e256acf12105244a1e24
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 11 November 2015 at 14:52, Tony V E <span dir=3D"ltr">&=
lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.c=
om</a>></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"><div dir=3D"ltr"><br><div class=3D"gm=
ail_extra">I'm not disagreeing, but the other example is vector<bool=
>.=C2=A0 (Allocators, vector<bool>, iostreams - things to be unfav=
ourably compared to).<br><br></div><div class=3D"gmail_extra">ie I was unsu=
re about expected<T, E> working differently when E is an exception, v=
s when E is an int or any other error.<br></div></div></blockquote><div><br=
></div><div>I'm not suggesting that either; we shouldn't have diffe=
rent behavior based on the type of E.</div><div><br></div><div>If we want d=
ifferent behavior, we should either have two differently named functions or=
two differently named classes.</div></div>-- <br><div class=3D"gmail_signa=
ture"><div dir=3D"ltr">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@cplusplusg=
uy.com</a>>=C2=A0 +1-847-691-1404<br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1141e256acf12105244a1e24--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 11 Nov 2015 13:08:13 -0800
Raw View
--001a113cf57c71f6fb05244a3990
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
> ie I was unsure about expected<T, E> working differently when E is an
> exception, vs when E is an int or any other error.
> Particularly since in C++, almost anything can be thrown as an exception.
> But we could define "is an exception" to be "derived from std::exception".
> Or is exception_ptr. Or...
>
This is my major gripe. I've implemented and used expected quite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113cf57c71f6fb05244a3990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 11, 2015 at 12:52 PM, Tony V E <span dir=3D"ltr"><<a href=3D"mai=
lto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span>=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">ie I wa=
s unsure about expected<T, E> working differently when E is an except=
ion, vs when E is an int or any other error.<br></div><div class=3D"gmail_e=
xtra">Particularly since in C++, almost anything can be thrown as an except=
ion.=C2=A0 But we could define "is an exception" to be "deri=
ved from std::exception".=C2=A0 Or is exception_ptr. Or...<br></div></=
div></blockquote><div><br></div><div>This is my major gripe. I've imple=
mented and used expected quite a bit, based around the proposal, but I leav=
e out the special handling for exception_ptr. I strongly feel that it is a =
mistake.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113cf57c71f6fb05244a3990--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 16:12:49 -0500
Raw View
--001a113fb8eadfed4705244a492b
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> I would like to re-raise the expected discussion. Beside the conflicting
> part "managing errors in a different way", that should be covered by a
> specific paper, I would like to open the discussion in order to have a
> better proposal for expected.
>
> There were some concerns about the exception throw when there is no value.
> I'm wondering if we can do as for basic_string, we can have an error_traits
> that define which exception is thrown and that can also do conversion from
> exception to errors.
>
> basic_expected<T, Error=exception _ptr, Traits=error_traits<Error>>
>
>
Not sure what I think of this, but I'll suggest it anyhow: make the traits
into wrapper classes:
0. expected<T, E> // default: if E is exception or exception_ptr throw
it, otherwise throw bad_access<E>
1. expected<T, as_error<Ex>> // even if Ex is an exception, treat it
like an error - ie always throw bad_access<Ex>
2. expected<T, as_exception<Err>> // even if Err is NOT an exception,
always throw Err
So really expected<T,E> looks for an expected-friendly interface on E
(similar to your traits interface), and if it finds it, it uses it.
Otherwise it uses its "magic" default behaviour. as_error<> and
as_exception<> would be two common ways of building the expected-friendly
interface.
Not sure if I like that any better. But it sort of lessens the weight for
the average 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113fb8eadfed4705244a492b
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 Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the
conflicting part "managing errors in a different way", that=
should
be covered by a specific paper, I would like to open the
discussion in order to have a better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is
no value. I'm wondering if we can do as for basic_string, we can
have an error_traits that define which exception is thrown and
that can also do conversion from exception to errors.<br>
<br>
basic_expected<T, Error=3Dexception _ptr,
Traits=3Derror_traits<Error>><br>
<br></font></div></blockquote><div><br></div></div>Not sure what I th=
ink of this, but I'll suggest it anyhow: make the traits into wrapper c=
lasses:<br><br></div><div class=3D"gmail_extra">0. =C2=A0=C2=A0 expected<=
;T, E> =C2=A0 // default: if E is exception or exception_ptr throw it, o=
therwise throw bad_access<E><br><br></div><div class=3D"gmail_extra">=
1. =C2=A0=C2=A0 expected<T, as_error<Ex>>=C2=A0 // even if Ex i=
s an exception, treat it like an error - ie always throw bad_access<Ex&g=
t;<br><br></div><div class=3D"gmail_extra">2. =C2=A0=C2=A0 expected<T, a=
s_exception<Err>> =C2=A0 // even if Err is NOT an exception, alway=
s throw Err<br><br></div><br>So really expected<T,E> looks for an exp=
ected-friendly interface on E (similar to your traits interface), and if it=
finds it, it uses it.=C2=A0 Otherwise it uses its "magic" defaul=
t behaviour.=C2=A0 as_error<> and as_exception<> would be two c=
ommon ways of building the expected-friendly interface.<br><br>Not sure if =
I like that any better.=C2=A0 But it sort of lessens the weight for the ave=
rage user.<br><div><div class=3D"gmail_extra"><br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113fb8eadfed4705244a492b--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:13:36 +0100
Raw View
Le 11/11/2015 21:37, Nevin Liber a =C3=A9crit :
> On 11 November 2015 at 14:01, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> There were some concerns about the exception throw when there is no valu=
e.
>> I'm wondering if we can do as for basic_string, we can have an error_tra=
its
>> that define which exception is thrown and that can also do conversion fr=
om
>> exception to errors.'
>>
> I'm not a fan of traits classes. They complicate interfaces to the point
> that virtually no one actually uses anything but the defaults.
>
> Let's take basic_string as the example. Other than standard library
> implementors testing their code, is there a string class out there in the
> wild whose only difference is a different traits class?
You should know this better than me ;-)
>
> Or you can take allocators as an example, which get more and more
> complicated with every revision of the standard and have gotten to the
> point that they infest classes that *never* do allocation (such as
> std::tuple) as well embarrassingly require support for them into classes
> that have no known way of being implemented (such as std::function and
> std::experimental::any, although we may be able to rescue that when have
> polymorphic allocator support in the standard).
I guess all these allocators are there so solve real problems isn't it?
>
> Instead of offering maximum flexibility, we should be making the hard
> choices (and they are hard) on what the right behavior is for the majorit=
y
> of users. The experts that need different behavior, being experts, can
> write and use their own classes.
>
> IMNSHO, of course...
The problem is that the expert I'm not, is not able to decide for you.=20
What would you propose as hard choice that is a good compromise?
Do you prefer the current proposal?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 11 Nov 2015 13:14:35 -0800
Raw View
--001a1134f1d837023005244a506e
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <calabrese@google.com>
wrote:
> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> ie I was unsure about expected<T, E> working differently when E is an
>> exception, vs when E is an int or any other error.
>> Particularly since in C++, almost anything can be thrown as an
>> exception. But we could define "is an exception" to be "derived from
>> std::exception". Or is exception_ptr. Or...
>>
>
> This is my major gripe. I've implemented and used expected quite a bit,
> based around the proposal, but I leave out the special handling for
> exception_ptr. I strongly feel that it is a mistake.
>
To be clear, I don't think there should be special handling/change in
behavior for "exceptions" being contained, not that std::exception_ptr was
too specific. I think the behavior should be consistent regardless of
whether or not E is assumed to be an 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1134f1d837023005244a506e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <span dir=3D"ltr"><<a href=
=3D"mailto:calabrese@google.com" target=3D"_blank">calabrese@google.com</a>=
></span> wrote:<br><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 =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, N=
ov 11, 2015 at 12:52 PM, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:t=
vaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">ie I was uns=
ure about expected<T, E> working differently when E is an exception, =
vs when E is an int or any other error.<br></div><div class=3D"gmail_extra"=
>Particularly since in C++, almost anything can be thrown as an exception.=
=C2=A0 But we could define "is an exception" to be "derived =
from std::exception".=C2=A0 Or is exception_ptr. Or...<br></div></div>=
</blockquote><div><br></div></span><div>This is my major gripe. I've im=
plemented and used expected quite a bit, based around the proposal, but I l=
eave out the special handling for exception_ptr. I strongly feel that it is=
a mistake.</div></div></div></div></blockquote></div></div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">To be clear, I don't t=
hink there should be special handling/change in behavior for "exceptio=
ns" being contained, not that std::exception_ptr was too specific. I t=
hink the behavior should be consistent regardless of whether or not E is as=
sumed to be an exception.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134f1d837023005244a506e--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 16:17:33 -0500
Raw View
--001a113fb8ead8b3f105244a5a95
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <calabrese@google.com>
> wrote:
>
>> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>> ie I was unsure about expected<T, E> working differently when E is an
>>> exception, vs when E is an int or any other error.
>>> Particularly since in C++, almost anything can be thrown as an
>>> exception. But we could define "is an exception" to be "derived from
>>> std::exception". Or is exception_ptr. Or...
>>>
>>
>> This is my major gripe. I've implemented and used expected quite a bit,
>> based around the proposal, but I leave out the special handling for
>> exception_ptr. I strongly feel that it is a mistake.
>>
>
> To be clear, I don't think there should be special handling/change in
> behavior for "exceptions" being contained, not that std::exception_ptr was
> too specific. I think the behavior should be consistent regardless of
> whether or not E is assumed to be an exception.
>
to be clear, just throw bad_access<exception_ptr> and
bad_access<MyException> and bad_access<int> when those are the types of Es?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113fb8ead8b3f105244a5a95
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 Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""=
><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, Nov 11, 2015=
at 1:08 PM, Matt Calabrese <span dir=3D"ltr"><<a href=3D"mailto:calabre=
se@google.com" target=3D"_blank">calabrese@google.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><span>On Wed, Nov 11, 2015 at 12:52 PM, Tony=
V E <span dir=3D"ltr"><<a href=3D"mailto:tvaneerd@gmail.com" target=3D"=
_blank">tvaneerd@gmail.com</a>></span> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra">ie I was unsure about expected<T, E&=
gt; working differently when E is an exception, vs when E is an int or any =
other error.<br></div><div class=3D"gmail_extra">Particularly since in C++,=
almost anything can be thrown as an exception.=C2=A0 But we could define &=
quot;is an exception" to be "derived from std::exception".=
=C2=A0 Or is exception_ptr. Or...<br></div></div></blockquote><div><br></di=
v></span><div>This is my major gripe. I've implemented and used expecte=
d quite a bit, based around the proposal, but I leave out the special handl=
ing for exception_ptr. I strongly feel that it is a mistake.</div></div></d=
iv></div></blockquote></div></div><div class=3D"gmail_extra"><br></div></sp=
an><div class=3D"gmail_extra">To be clear, I don't think there should b=
e special handling/change in behavior for "exceptions" being cont=
ained, not that std::exception_ptr was too specific. I think the behavior s=
hould be consistent regardless of whether or not E is assumed to be an exce=
ption.</div></div></blockquote><div><br></div></div>to be clear, just throw=
bad_access<exception_ptr> and bad_access<MyException> and bad_=
access<int> when those are the types of Es?<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113fb8ead8b3f105244a5a95--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:18:17 +0100
Raw View
Le 11/11/2015 21:52, Tony V E a =C3=A9crit :
> On Wed, Nov 11, 2015 at 3:37 PM, Nevin Liber <nevin@cplusplusguy.com> wro=
te:
>
>> On 11 November 2015 at 14:01, Vicente J. Botet Escriba <
>> vicente.botet@wanadoo.fr> wrote:
>>
>>> There were some concerns about the exception throw when there is no
>>> value. I'm wondering if we can do as for basic_string, we can have an
>>> error_traits that define which exception is thrown and that can also do
>>> conversion from exception to errors.'
>>>
>> I'm not a fan of traits classes. They complicate interfaces to the poin=
t
>> that virtually no one actually uses anything but the defaults.
>>
>> Let's take basic_string as the example. Other than standard library
>> implementors testing their code, is there a string class out there in th=
e
>> wild whose only difference is a different traits class?
>>
>> Or you can take allocators as an example, which get more and more
>> complicated with every revision of the standard and have gotten to the
>> point that they infest classes that *never* do allocation (such as
>> std::tuple) as well embarrassingly require support for them into classes
>> that have no known way of being implemented (such as std::function and
>> std::experimental::any, although we may be able to rescue that when have
>> polymorphic allocator support in the standard).
>>
>> Instead of offering maximum flexibility, we should be making the hard
>> choices (and they are hard) on what the right behavior is for the majori=
ty
>> of users. The experts that need different behavior, being experts, can
>> write and use their own classes.
>>
>> IMNSHO, of course...
>> --
>> Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com
>> <nevin@eviloverlord.com>> +1-847-691-1404
>>
>> --
>>
> I'm not disagreeing, but the other example is vector<bool>. (Allocators,
> vector<bool>, iostreams - things to be unfavourably compared to).
>
> ie I was unsure about expected<T, E> working differently when E is an
> exception, vs when E is an int or any other error.
The single difference currently is between exception_ptr or anything else
> Particularly since in C++, almost anything can be thrown as an exception.
> But we could define "is an exception" to be "derived from std::exception"=
..
> Or is exception_ptr. Or...
>
> On the other hand, I kind of agree that if E is an exception, the user
> probably expects it to be thrown if they call value() and the value is no=
t
> there.
>
> Vicente, what are all the differences, in the most recent proposal, betwe=
en
> handling exceptions vs errors?
> ie where/when/how would these traits be called?
>
>
Currently there is already some internal error_trait that is not part of=20
the class interface. The behavior was refined for exception_ptr, so that=20
we throw the exception contained in the exception_ptr. For the other we=20
throw bad_expected_access as optional does.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:19:30 +0100
Raw View
This is a multi-part message in MIME format.
--------------010402000107070609020808
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/11/2015 22:00, Nevin Liber a =C3=A9crit :
> On 11 November 2015 at 14:52, Tony V E <tvaneerd@gmail.com> wrote:
>
>> I'm not disagreeing, but the other example is vector<bool>. (Allocators=
,
>> vector<bool>, iostreams - things to be unfavourably compared to).
>>
>> ie I was unsure about expected<T, E> working differently when E is an
>> exception, vs when E is an int or any other error.
>>
> I'm not suggesting that either; we shouldn't have different behavior base=
d
> on the type of E.
>
> If we want different behavior, we should either have two differently name=
d
> functions or two differently named classes.
Could you elaborate? Some examples e.g; with error_code,=20
error_consdition, ....
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------010402000107070609020808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/11/2015 22:00, Nevin Liber a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAGg_6+N1SyDk-furNvvZFMONps8O27b--=3D+eqkprPkpg_R7umw@mail.gmai=
l.com"
type=3D"cite">
<pre wrap=3D"">On 11 November 2015 at 14:52, Tony V E <a class=3D"moz=
-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvaneerd@gmail.c=
om></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
I'm not disagreeing, but the other example is vector<bool>. (Allocat=
ors,
vector<bool>, iostreams - things to be unfavourably compared to).
ie I was unsure about expected<T, E> working differently when E is an
exception, vs when E is an int or any other error.
</pre>
</blockquote>
<pre wrap=3D"">
I'm not suggesting that either; we shouldn't have different behavior based
on the type of E.
If we want different behavior, we should either have two differently named
functions or two differently named classes.
</pre>
</blockquote>
<font size=3D"+1">Could you elaborate? Some examples e.g; with
error_code, error_consdition, ....<br>
<br>
<br>
Vicente </font><br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010402000107070609020808--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 11 Nov 2015 13:21:22 -0800
Raw View
--047d7b414028759bf605244a687a
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>
> On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <calabrese@google.com>
>> wrote:
>>
>>> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>>>
>>>> ie I was unsure about expected<T, E> working differently when E is an
>>>> exception, vs when E is an int or any other error.
>>>> Particularly since in C++, almost anything can be thrown as an
>>>> exception. But we could define "is an exception" to be "derived from
>>>> std::exception". Or is exception_ptr. Or...
>>>>
>>>
>>> This is my major gripe. I've implemented and used expected quite a bit,
>>> based around the proposal, but I leave out the special handling for
>>> exception_ptr. I strongly feel that it is a mistake.
>>>
>>
>> To be clear, I don't think there should be special handling/change in
>> behavior for "exceptions" being contained, not that std::exception_ptr was
>> too specific. I think the behavior should be consistent regardless of
>> whether or not E is assumed to be an exception.
>>
>
> to be clear, just throw bad_access<exception_ptr> and
> bad_access<MyException> and bad_access<int> when those are the types of Es?
>
Ultimately being consistent is the most important thing to me here, but in
my opinion they should all *never* throw.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b414028759bf605244a687a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 11, 2015 at 1:17 PM, Tony V E <span dir=3D"ltr"><<a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D=
"gmail_extra"><div><div class=3D"h5"><br><div class=3D"gmail_quote">On Wed,=
Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard - F=
uture Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocp=
p.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote">On Wed, Nov 11, 2015 at 1:08 PM, Matt Cala=
brese <span dir=3D"ltr"><<a href=3D"mailto:calabrese@google.com" target=
=3D"_blank">calabrese@google.com</a>></span> wrote:<br><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"><span>On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <span dir=3D"ltr=
"><<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmai=
l.com</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra">ie I was unsure about expected<T, E> working differently=
when E is an exception, vs when E is an int or any other error.<br></div><=
div class=3D"gmail_extra">Particularly since in C++, almost anything can be=
thrown as an exception.=C2=A0 But we could define "is an exception&qu=
ot; to be "derived from std::exception".=C2=A0 Or is exception_pt=
r. Or...<br></div></div></blockquote><div><br></div></span><div>This is my =
major gripe. I've implemented and used expected quite a bit, based arou=
nd the proposal, but I leave out the special handling for exception_ptr. I =
strongly feel that it is a mistake.</div></div></div></div></blockquote></d=
iv></div><div class=3D"gmail_extra"><br></div></span><div class=3D"gmail_ex=
tra">To be clear, I don't think there should be special handling/change=
in behavior for "exceptions" being contained, not that std::exce=
ption_ptr was too specific. I think the behavior should be consistent regar=
dless of whether or not E is assumed to be an exception.</div></div></block=
quote><div><br></div></div></div></div>to be clear, just throw bad_access&l=
t;exception_ptr> and bad_access<MyException> and bad_access<int=
> when those are the types of Es?</div></div></blockquote><div><br></div=
><div>Ultimately being consistent is the most important thing to me here, b=
ut in my opinion they should all *never* throw.<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b414028759bf605244a687a--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:21:16 +0100
Raw View
This is a multi-part message in MIME format.
--------------080303010506030705020105
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/11/2015 22:08, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> ie I was unsure about expected<T, E> working differently when E is an
>> exception, vs when E is an int or any other error.
>> Particularly since in C++, almost anything can be thrown as an exception=
..
>> But we could define "is an exception" to be "derived from std::exception=
".
>> Or is exception_ptr. Or...
>>
> This is my major gripe. I've implemented and used expected quite a bit,
> based around the proposal, but I leave out the special handling for
> exception_ptr. I strongly feel that it is a mistake.
>
Are you saying that expected<T,exception_ptr> should not throw the=20
stored exception in the exception_ptr as future does?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------080303010506030705020105
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/11/2015 22:08, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CANh8DEmrgS3qD-AT=3Dgi+xpuOBv_emrwZh-fNm+xxr0RHFLRV_A@mail.gmai=
l.com"
type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <a class=3D=
"moz-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvaneerd@gma=
il.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
ie I was unsure about expected<T, E> working differently when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an exception.
But we could define "is an exception" to be "derived from std::exception".
Or is exception_ptr. Or...
</pre>
</blockquote>
<pre wrap=3D"">
This is my major gripe. I've implemented and used expected quite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
</pre>
</blockquote>
<font size=3D"+1">Are you saying that expected</font><T,exception_pt=
r>
should not throw the stored exception in the exception_ptr as future
does?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------080303010506030705020105--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:26:47 +0100
Raw View
This is a multi-part message in MIME format.
--------------080701070001010504080303
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/11/2015 22:21, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>> On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <calabrese@google.com>
>>> wrote:
>>>
>>>> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>>>> ie I was unsure about expected<T, E> working differently when E is an
>>>>> exception, vs when E is an int or any other error.
>>>>> Particularly since in C++, almost anything can be thrown as an
>>>>> exception. But we could define "is an exception" to be "derived from
>>>>> std::exception". Or is exception_ptr. Or...
>>>>>
>>>> This is my major gripe. I've implemented and used expected quite a bit=
,
>>>> based around the proposal, but I leave out the special handling for
>>>> exception_ptr. I strongly feel that it is a mistake.
>>>>
>>> To be clear, I don't think there should be special handling/change in
>>> behavior for "exceptions" being contained, not that std::exception_ptr =
was
>>> too specific. I think the behavior should be consistent regardless of
>>> whether or not E is assumed to be an exception.
>>>
>> to be clear, just throw bad_access<exception_ptr> and
>> bad_access<MyException> and bad_access<int> when those are the types of =
Es?
>>
> Ultimately being consistent is the most important thing to me here, but i=
n
> my opinion they should all *never* throw.
>
What others think of throwing just E?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------080701070001010504080303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/11/2015 22:21, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CANh8DE=3DfTGTgeJq3g0dP+1hVzu_Xxn+aR=3DukK_REsD-SY_k9Sg@mail.gm=
ail.com"
type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <a class=3D"=
moz-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvaneerd@gmai=
l.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:std-prop=
osals@isocpp.org"><std-proposals@isocpp.org></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <a=
class=3D"moz-txt-link-rfc2396E" href=3D"mailto:calabrese@google.com"><c=
alabrese@google.com></a>
wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <a cl=
ass=3D"moz-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvanee=
rd@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
ie I was unsure about expected<T, E> working differently when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an
exception. But we could define "is an exception" to be "derived from
std::exception". Or is exception_ptr. Or...
</pre>
</blockquote>
<pre wrap=3D"">
This is my major gripe. I've implemented and used expected quite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
</pre>
</blockquote>
<pre wrap=3D"">
To be clear, I don't think there should be special handling/change in
behavior for "exceptions" being contained, not that std::exception_ptr was
too specific. I think the behavior should be consistent regardless of
whether or not E is assumed to be an exception.
</pre>
</blockquote>
<pre wrap=3D"">
to be clear, just throw bad_access<exception_ptr> and
bad_access<MyException> and bad_access<int> when those are the =
types of Es?
</pre>
</blockquote>
<pre wrap=3D"">
Ultimately being consistent is the most important thing to me here, but in
my opinion they should all *never* throw.
</pre>
</blockquote>
<font size=3D"+1">What others think of throwing just E?<br>
<br>
Vicente<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------080701070001010504080303--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:27:06 +0100
Raw View
Le 11/11/2015 22:12, Tony V E a =C3=A9crit :
> On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Hi,
>>
>> I would like to re-raise the expected discussion. Beside the conflicting
>> part "managing errors in a different way", that should be covered by a
>> specific paper, I would like to open the discussion in order to have a
>> better proposal for expected.
>>
>> There were some concerns about the exception throw when there is no valu=
e.
>> I'm wondering if we can do as for basic_string, we can have an error_tra=
its
>> that define which exception is thrown and that can also do conversion fr=
om
>> exception to errors.
>>
>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>>
>>
>>
> Not sure what I think of this, but I'll suggest it anyhow: make the trait=
s
> into wrapper classes:
>
> 0. expected<T, E> // default: if E is exception or exception_ptr thr=
ow
> it, otherwise throw bad_access<E>
>
> 1. expected<T, as_error<Ex>> // even if Ex is an exception, treat it
> like an error - ie always throw bad_access<Ex>
>
> 2. expected<T, as_exception<Err>> // even if Err is NOT an exception=
,
> always throw Err
>
>
> So really expected<T,E> looks for an expected-friendly interface on E
> (similar to your traits interface), and if it finds it, it uses it.
> Otherwise it uses its "magic" default behaviour. as_error<> and
> as_exception<> would be two common ways of building the expected-friendly
> interface.
>
> Not sure if I like that any better. But it sort of lessens the weight fo=
r
> the average user.
>
Are you proposing that expected is aware of as_error and as_exception?
What other think of this interface?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 11 Nov 2015 13:27:35 -0800
Raw View
--001a11c2e6aeb9093f05244a7ecf
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 1:21 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 11/11/2015 22:08, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals a =C3=A9crit :
>
> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> <tvaneerd=
@gmail.com> wrote:
>
> ie I was unsure about expected<T, E> working differently when E is an
> exception, vs when E is an int or any other error.
> Particularly since in C++, almost anything can be thrown as an exception.
> But we could define "is an exception" to be "derived from std::exception"=
..
> Or is exception_ptr. Or...
>
>
> This is my major gripe. I've implemented and used expected quite a bit,
> based around the proposal, but I leave out the special handling for
> exception_ptr. I strongly feel that it is a mistake.
>
>
> Are you saying that expected<T,exception_ptr> should not throw the stored
> exception in the exception_ptr as future does?
>
Yeah, that's my opinion. I think std::future is a bit different, though. I
actually do not have a problem with std::future throwing because that is
the specified behavior regardless of T.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2e6aeb9093f05244a7ecf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 11, 2015 at 1:21 PM, Vicente J. Botet Escriba <span dir=3D"ltr"><=
;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bote=
t@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div class=3D"h5">
<div>Le 11/11/2015 22:08, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<pre>On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <a href=3D"mailto:tva=
neerd@gmail.com" target=3D"_blank"><tvaneerd@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>ie I was unsure about expected<T, E> working differently=
when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an exception.
But we could define "is an exception" to be "derived from st=
d::exception".
Or is exception_ptr. Or...
</pre>
</blockquote>
<pre>This is my major gripe. I've implemented and used expected q=
uite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
</pre>
</blockquote>
</div></div><font size=3D"+1">Are you saying that expected</font><T,=
exception_ptr>
should not throw the stored exception in the exception_ptr as future
does?</div></blockquote><div><br></div><div>Yeah, that's my opinion=
.. I think std::future is a bit different, though. I actually do not have a =
problem with std::future throwing because that is the specified behavior re=
gardless of T.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2e6aeb9093f05244a7ecf--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:27:56 +0100
Raw View
Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :
>
> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Hi,
>>
>> I would like to re-raise the expected discussion. Beside the conflicting
>> part "managing errors in a different way", that should be covered by a
>> specific paper, I would like to open the discussion in order to have a
>> better proposal for expected.
>>
>> There were some concerns about the exception throw when there is no valu=
e.
>> I'm wondering if we can do as for basic_string, we can have an error_tra=
its
>> that define which exception is thrown and that can also do conversion fr=
om
>> exception to errors.
>>
> Here's my feeling on this.
>
> If you have some expected object and you do `.value` on it (or any of its
> equivalents), what you are saying very clearly is this: I fully and
> completely expect that this object will not be in the error state. That's
> the conceptual precondition of your code.
No. value is a wide interface. We could add a narrow dereference=20
function if we think is useful.
>
> If that condition is violated, then the problem with your code is that th=
e
> condition was violated. That is, the problem with your code is not that a
> function emitted an error of some type. It's that a function emitted an
> error and *you didn't check it*. This is the same error no matter what th=
e
> error code type is, so it should throw the same exception from every
> `expected` object.
You reached to lost me. have you read the expected proposal?
> That being said, I could see having a `throw_if_error` function, which wi=
ll
> throw an exception based on the error code if the expected object is in t=
he
> error state.
Oh, I see that you have not, or you have forgotten the proposed interface?
>
> Also, we don't want to overburden `expected` with customization machinery=
..
> Not unless there's a really good reason. I don't want to have to hunt dow=
n
> some traits class to see what I should have to catch. Throwing the error
> code type itself, whatever that type is, should be sufficient for a
> function like `throw_if_error`.
Please, refer to the proposal. Do you mean that expected<T,E>::value()=20
should throw an exception E?
What about expected<T,exception_ptr>, should throw an exception_ptr?
>
> After all, I've always felt that the point of `expected` was to *not* use
> exceptions, to have an alternative to them.
Some could make this use, but expected works very well with exceptions.=20
There is no either you use exceptions or you use expected decision to make.
> It seems kinda silly to add a
> customization point solely for exception behavior, when that's exactly wh=
at
> you're trying to avoid.
>
It seems that you don't understand the purpose of expected. If proposed=20
expected is able to throw an exception when there is no value. That's it.
The question is which exception.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 22:36:07 +0100
Raw View
This is a multi-part message in MIME format.
--------------040806080708060305080500
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/11/2015 22:27, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Nov 11, 2015 at 1:21 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Le 11/11/2015 22:08, 'Matt Calabrese' via ISO C++ Standard - Future
>> Proposals a =C3=A9crit :
>>
>> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> <tvaneer=
d@gmail.com> wrote:
>>
>> ie I was unsure about expected<T, E> working differently when E is an
>> exception, vs when E is an int or any other error.
>> Particularly since in C++, almost anything can be thrown as an exception=
..
>> But we could define "is an exception" to be "derived from std::exception=
".
>> Or is exception_ptr. Or...
>>
>>
>> This is my major gripe. I've implemented and used expected quite a bit,
>> based around the proposal, but I leave out the special handling for
>> exception_ptr. I strongly feel that it is a mistake.
>>
>>
>> Are you saying that expected<T,exception_ptr> should not throw the store=
d
>> exception in the exception_ptr as future does?
>>
> Yeah, that's my opinion. I think std::future is a bit different, though. =
I
> actually do not have a problem with std::future throwing because that is
> the specified behavior regardless of T.
>
Would you be against/for having two classes
expected<T>
throws the exception stored in the exception_ptr
expected_or_error<T,E> // or whatever better name we find
throws E
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------040806080708060305080500
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/11/2015 22:27, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CANh8DE=3Dt=3D200o3yOmK0XLFp1NUoFX=3DGt1yaKi58c3L1TCEobQg@mail.=
gmail.com"
type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 1:21 PM, Vicente J. Botet Escr=
iba <
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:vicente.botet@wanadoo.=
fr">vicente.botet@wanadoo.fr</a>> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Le 11/11/2015 22:08, 'Matt Calabrese' via ISO C++ St=
andard - Future
Proposals a =C3=A9crit :
On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <a class=3D"moz-txt-link-rfc2396=
E" href=3D"mailto:tvaneerd@gmail.com"><tvaneerd@gmail.com></a> <a cla=
ss=3D"moz-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvaneer=
d@gmail.com></a> wrote:
ie I was unsure about expected<T, E> working differently when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an exception.
But we could define "is an exception" to be "derived from std::exception".
Or is exception_ptr. Or...
This is my major gripe. I've implemented and used expected quite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
Are you saying that expected<T,exception_ptr> should not throw the st=
ored
exception in the exception_ptr as future does?
</pre>
</blockquote>
<pre wrap=3D"">
Yeah, that's my opinion. I think std::future is a bit different, though. I
actually do not have a problem with std::future throwing because that is
the specified behavior regardless of T.
</pre>
</blockquote>
<font size=3D"+1">Would you be against/for having two classes<br>
<br>
expected<T> <br>
<br>
throws the exception stored in the exception_ptr<br>
<br>
expected_or_error<T,E> // or whatever better name we find<br>
<br>
</font><font size=3D"+1"><font size=3D"+1">throws E<br>
</font><br>
Vicente<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------040806080708060305080500--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 11 Nov 2015 13:40:19 -0800
Raw View
--001a11c2578a3ddae705244aac1b
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 12:29 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> If you have some expected object and you do `.value` on it (or any of its
> equivalents), what you are saying very clearly is this: I fully and
> completely expect that this object will not be in the error state. That's
> the conceptual precondition of your code.
>
+1
I understand that one of the main points of the proposal is to throw here.
I disagree with this aspect, but I like the facility in general. This
should really just be a precondition violation and UB (maybe contracts
would provide a satisfying answer for both parties once more progress is
made on that front). At the very least, if we throw then we should be
consistent for all E, but I really do feel that the only thing we
accomplish by throwing is either A) endorsing the use of exceptions for
basic control flow -or- B) propagating an exception when a user's
assumptions about program invariants do not hold. Neither of these are very
desirable.
That said, the standard library does throw in many places where I feel it
is a mistake, and we are only seeing more of such uses of exceptions rather
than less. I'll voice my opinion that I think it's a problem whenever that
happens, but really the inconsistency is the big issue that I have. It
should either always be specified to be UB or always be specified to throw.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2578a3ddae705244aac1b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 11, 2015 at 12:29 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<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>If you hav=
e some expected object and you do `.value` on it (or any of its equivalents=
), what you are saying very clearly is this: I fully and completely expect =
that this object will not be in the error state. That's the conceptual =
precondition of your code.</div></div></blockquote></div><br></div><div cla=
ss=3D"gmail_extra">+1</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">I understand that one of the main points of the proposal i=
s to throw here. I disagree with this aspect, but I like the facility in ge=
neral. This should really just be a precondition violation and UB (maybe co=
ntracts would provide a satisfying answer for both parties once more progre=
ss is made on that front). At the very least, if we throw then we should be=
consistent for all E, but I really do feel that the only thing we accompli=
sh by throwing is either A) endorsing the use of exceptions for basic contr=
ol flow -or- B) propagating an exception when a user's assumptions abou=
t program invariants do not hold. Neither of these are very desirable.</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">That said,=
the standard library does throw in many places where I feel it is a mistak=
e, and we are only seeing more of such uses of exceptions rather than less.=
I'll voice my opinion that I think it's a problem whenever that ha=
ppens, but really the inconsistency is the big issue that I have. It should=
either always be specified to be UB or always be specified to throw.</div>=
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2578a3ddae705244aac1b--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 11 Nov 2015 13:56:17 -0800
Raw View
--089e0115f05259d67405244ae58e
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 1:36 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
>
> Would you be against/for having two classes
>
> expected<T>
>
> throws the exception stored in the exception_ptr
>
> expected_or_error<T,E> // or whatever better name we find
>
> throws E
>
I'd rather just have a single excepted<T, E> and either always specify
throw or always specify UB. If I happen to be there for a poll for an
expected proposal where expected<T, E> always specifies throw, I would not
vote against it just because of that alone. The facility is very useful
regardless and the difference doesn't impact my uses enough. As long as the
template is consistent, I'm happy enough. I would, however, vote against
the proposal if it threw *only* when E is std::exception_ptr or is
otherwise determined to be an "exception" type.
So, my thoughts are just 1 template that is consistent, regardless of
whether than means always specify throwing or always specifying UB.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0115f05259d67405244ae58e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 11, 2015 at 1:36 PM, Vicente J. Botet Escriba <span dir=3D"ltr"><=
;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bote=
t@wanadoo.fr</a>></span> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgc=
olor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Would you be against/for having two classes<br>
<br>
expected<T> <br>
<br>
throws the exception stored in the exception_ptr<br>
<br>
expected_or_error<T,E> // or whatever better name we find<br>
<br>
</font><font size=3D"+1"><font size=3D"+1">throws E</font></font></div>=
</blockquote><div><br></div><div>I'd rather just have a single excepted=
<T, E> and either always specify throw or always specify UB. If I hap=
pen to be there for a poll for an expected proposal where expected<T, E&=
gt; always specifies throw, I would not vote against it just because of tha=
t alone. The facility is very useful regardless and the difference doesn=
9;t impact my uses enough. As long as the template is consistent, I'm h=
appy enough. I would, however, vote against the proposal if it threw *only*=
when E is std::exception_ptr or is otherwise determined to be an "exc=
eption" type.</div><div><br></div><div>So, my thoughts are just 1 temp=
late that is consistent, regardless of whether than means always specify th=
rowing or always specifying UB.</div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0115f05259d67405244ae58e--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 17:19:01 -0500
Raw View
--001a11410c32af5ae305244b364e
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 11, 2015 at 4:56 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> On Wed, Nov 11, 2015 at 1:36 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>>
>> Would you be against/for having two classes
>>
>> expected<T>
>>
>> throws the exception stored in the exception_ptr
>>
>> expected_or_error<T,E> // or whatever better name we find
>>
>> throws E
>>
>
> I'd rather just have a single excepted<T, E> and either always specify
> throw or always specify UB. If I happen to be there for a poll for an
> expected proposal where expected<T, E> always specifies throw, I would not
> vote against it just because of that alone. The facility is very useful
> regardless and the difference doesn't impact my uses enough. As long as the
> template is consistent, I'm happy enough. I would, however, vote against
> the proposal if it threw *only* when E is std::exception_ptr or is
> otherwise determined to be an "exception" type.
>
> So, my thoughts are just 1 template that is consistent, regardless of
> whether than means always specify throwing or always specifying UB.
>
>
To match optional and variant, it isn't going to be UB. It is going to
throw. The question is what should expected<Foo,int> throw? Should it
just throw int? Or throw bad_expected_access<int> (similar to
optional.value() which throws bad_optional_access).
And then what should expected<Foo, exception_ptr> throw?
If you want UB, call operator*(). Same as optional; similar to vector[] vs
vector.at().
--
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11410c32af5ae305244b364e
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 Wed, Nov 11, 2015 at 4:56 PM, 'Matt Calabrese' via ISO C++ S=
tandard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-prop=
osals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On Wed, Nov 11, 2015=
at 1:36 PM, Vicente J. Botet Escriba <span dir=3D"ltr"><<a href=3D"mail=
to:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>=
></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">
<font size=3D"+1">Would you be against/for having two classes<br>
<br>
expected<T> <br>
<br>
throws the exception stored in the exception_ptr<br>
<br>
expected_or_error<T,E> // or whatever better name we find<br>
<br>
</font><font size=3D"+1"><font size=3D"+1">throws E</font></font></div>=
</blockquote><div><br></div></span><div>I'd rather just have a single e=
xcepted<T, E> and either always specify throw or always specify UB. I=
f I happen to be there for a poll for an expected proposal where expected&l=
t;T, E> always specifies throw, I would not vote against it just because=
of that alone. The facility is very useful regardless and the difference d=
oesn't impact my uses enough. As long as the template is consistent, I&=
#39;m happy enough. I would, however, vote against the proposal if it threw=
*only* when E is std::exception_ptr or is otherwise determined to be an &q=
uot;exception" type.</div><div><br></div><div>So, my thoughts are just=
1 template that is consistent, regardless of whether than means always spe=
cify throwing or always specifying UB.</div></div><br></div></div></blockqu=
ote><div><br></div><div>To match optional and variant, it isn't going t=
o be UB.=C2=A0 It is going to throw.=C2=A0 The question is what should expe=
cted<Foo,int> throw?=C2=A0 Should it just throw int?=C2=A0 Or throw b=
ad_expected_access<int> (similar to optional.value() which throws bad=
_optional_access).<br></div><div>And then what should expected<Foo, exce=
ption_ptr> throw?<br></div><div><br></div><div>If you want UB, call oper=
ator*().=C2=A0 Same as optional; similar to vector[] vs <a href=3D"http://v=
ector.at">vector.at</a>().<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div class=3D"gmail_extra"></div></div><div class=3D"HOEnZb"><=
div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11410c32af5ae305244b364e--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 17:25:29 -0500
Raw View
--001a11c377a2c24be505244b4dac
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 4:27 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 11/11/2015 22:12, Tony V E a =C3=A9crit :
>
>> On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <
>> vicente.botet@wanadoo.fr> wrote:
>>
>> Hi,
>>>
>>> I would like to re-raise the expected discussion. Beside the conflictin=
g
>>> part "managing errors in a different way", that should be covered by a
>>> specific paper, I would like to open the discussion in order to have a
>>> better proposal for expected.
>>>
>>> There were some concerns about the exception throw when there is no
>>> value.
>>> I'm wondering if we can do as for basic_string, we can have an
>>> error_traits
>>> that define which exception is thrown and that can also do conversion
>>> from
>>> exception to errors.
>>>
>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>>
>>>
>>>
>>> Not sure what I think of this, but I'll suggest it anyhow: make the
>> traits
>> into wrapper classes:
>>
>> 0. expected<T, E> // default: if E is exception or exception_ptr
>> throw
>> it, otherwise throw bad_access<E>
>>
>> 1. expected<T, as_error<Ex>> // even if Ex is an exception, treat it
>> like an error - ie always throw bad_access<Ex>
>>
>> 2. expected<T, as_exception<Err>> // even if Err is NOT an exceptio=
n,
>> always throw Err
>>
>>
>> So really expected<T,E> looks for an expected-friendly interface on E
>> (similar to your traits interface), and if it finds it, it uses it.
>> Otherwise it uses its "magic" default behaviour. as_error<> and
>> as_exception<> would be two common ways of building the expected-friendl=
y
>> interface.
>>
>> Not sure if I like that any better. But it sort of lessens the weight f=
or
>> the average user.
>>
>> Are you proposing that expected is aware of as_error and as_exception?
>
>
Not exactly. It only appears that way. In reality, it would probably be
that as_error<> and as_exception<> either both derive from
expected_error_handler_interface or at least both implement the right
member functions which are detected at compile time.
So you could pass in your own E that happens to implement the correct
interface, and we just happen to supply 2 common/useful examples.
It's very similar to traits. Just sort or moves where/how the
customization happens.
What other think of this interface?
>
>
> Vicente
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c377a2c24be505244b4dac
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 Wed, Nov 11, 2015 at 4:27 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div class=3D""><div class=3D"h5">Le 11/11/2015 22:12,=
Tony V E a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <<br>
<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet=
@wanadoo.fr</a>> wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the conflicting<br=
>
part "managing errors in a different way", that should be covered=
by a<br>
specific paper, I would like to open the discussion in order to have a<br>
better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is no value.<=
br>
I'm wondering if we can do as for basic_string, we can have an error_tr=
aits<br>
that define which exception is thrown and that can also do conversion from<=
br>
exception to errors.<br>
<br>
basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error=
>><br>
<br>
<br>
</blockquote>
Not sure what I think of this, but I'll suggest it anyhow: make the tra=
its<br>
into wrapper classes:<br>
<br>
0.=C2=A0 =C2=A0 expected<T, E>=C2=A0 =C2=A0// default: if E is except=
ion or exception_ptr throw<br>
it, otherwise throw bad_access<E><br>
<br>
1.=C2=A0 =C2=A0 expected<T, as_error<Ex>>=C2=A0 // even if Ex i=
s an exception, treat it<br>
like an error - ie always throw bad_access<Ex><br>
<br>
2.=C2=A0 =C2=A0 expected<T, as_exception<Err>>=C2=A0 =C2=A0// e=
ven if Err is NOT an exception,<br>
always throw Err<br>
<br>
<br>
So really expected<T,E> looks for an expected-friendly interface on E=
<br>
(similar to your traits interface), and if it finds it, it uses it.<br>
Otherwise it uses its "magic" default behaviour.=C2=A0 as_error&l=
t;> and<br>
as_exception<> would be two common ways of building the expected-frie=
ndly<br>
interface.<br>
<br>
Not sure if I like that any better.=C2=A0 But it sort of lessens the weight=
for<br>
the average user.<br>
<br>
</blockquote></div></div>
Are you proposing that expected is aware of as_error and as_exception?<br>
<br></blockquote><div><br></div><div>Not exactly.=C2=A0 It only appears tha=
t way.=C2=A0 In reality, it would probably be that as_error<> and as_=
exception<> either both derive from expected_error_handler_interface =
or at least both implement the right member functions which are detected at=
compile time.<br></div><div>So you could pass in your own E that happens t=
o implement the correct interface, and we just happen to supply 2 common/us=
eful examples.<br><br></div><div>It's very similar to traits.=C2=A0 Jus=
t sort or moves where/how the customization happens.<br></div><div><br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
What other think of this interface?<span class=3D""><font color=3D"#888888"=
><br>
<br>
<br>
Vicente</font></span><div class=3D""><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c377a2c24be505244b4dac--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 23:30:48 +0100
Raw View
This is a multi-part message in MIME format.
--------------030807010006010802060901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/11/2015 22:40, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Nov 11, 2015 at 12:29 PM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>> If you have some expected object and you do `.value` on it (or any of it=
s
>> equivalents), what you are saying very clearly is this: I fully and
>> completely expect that this object will not be in the error state. That'=
s
>> the conceptual precondition of your code.
>>
> +1
>
> I understand that one of the main points of the proposal is to throw here=
..
> I disagree with this aspect, but I like the facility in general. This
> should really just be a precondition violation and UB (maybe contracts
> would provide a satisfying answer for both parties once more progress is
> made on that front). At the very least, if we throw then we should be
> consistent for all E, but I really do feel that the only thing we
> accomplish by throwing is either A) endorsing the use of exceptions for
> basic control flow -or- B) propagating an exception when a user's
> assumptions about program invariants do not hold. Neither of these are ve=
ry
> desirable.
>
> That said, the standard library does throw in many places where I feel it
> is a mistake, and we are only seeing more of such uses of exceptions rath=
er
> than less. I'll voice my opinion that I think it's a problem whenever tha=
t
> happens, but really the inconsistency is the big issue that I have. It
> should either always be specified to be UB or always be specified to thro=
w.
>
As currently it is often specified for both cases, should we provide=20
value() that throws and operator* that is UB when there is no value?
"
In order to be as efficient as possible, this proposal includes=20
observers with narrow and wide contracts. Thus, the value() function has=20
a wide contract. If the expected object doesn=E2=80=99t contain a value, an=
=20
exception is thrown. However, when the user knows that the expected=20
object is valid, the use of operator* would be more appropriated.
"
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------030807010006010802060901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/11/2015 22:40, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CANh8DEmNGfwZr5O8hNm+Ye5qxKqCw2DwNbh6WmfHqMuD6f6Snw@mail.gmail.=
com"
type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 12:29 PM, Nicol Bolas <a class=
=3D"moz-txt-link-rfc2396E" href=3D"mailto:jmckesson@gmail.com"><jmckesso=
n@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
If you have some expected object and you do `.value` on it (or any of its
equivalents), what you are saying very clearly is this: I fully and
completely expect that this object will not be in the error state. That's
the conceptual precondition of your code.
</pre>
</blockquote>
<pre wrap=3D"">
+1
I understand that one of the main points of the proposal is to throw here.
I disagree with this aspect, but I like the facility in general. This
should really just be a precondition violation and UB (maybe contracts
would provide a satisfying answer for both parties once more progress is
made on that front). At the very least, if we throw then we should be
consistent for all E, but I really do feel that the only thing we
accomplish by throwing is either A) endorsing the use of exceptions for
basic control flow -or- B) propagating an exception when a user's
assumptions about program invariants do not hold. Neither of these are very
desirable.
That said, the standard library does throw in many places where I feel it
is a mistake, and we are only seeing more of such uses of exceptions rather
than less. I'll voice my opinion that I think it's a problem whenever that
happens, but really the inconsistency is the big issue that I have. It
should either always be specified to be UB or always be specified to throw.
</pre>
</blockquote>
As currently it is often specified for both cases, should we provide
value() that throws and operator* that is UB when there is no value?<br=
>
<br>
"<br>
<meta charset=3D"utf-8">
In order to be as efficient as possible, this proposal includes
observers with narrow and wide contracts. Thus,
the value() function has a wide contract. If the expected object
doesn=E2=80=99t contain a value, an exception is
thrown. However, when the user knows that the expected object is
valid, the use of operator* would be more
appropriated.<br>
"<br>
<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------030807010006010802060901--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 23:34:42 +0100
Raw View
Le 11/11/2015 23:19, Tony V E a =C3=A9crit :
> On Wed, Nov 11, 2015 at 4:56 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> On Wed, Nov 11, 2015 at 1:36 PM, Vicente J. Botet Escriba <
>> vicente.botet@wanadoo.fr> wrote:
>>> Would you be against/for having two classes
>>>
>>> expected<T>
>>>
>>> throws the exception stored in the exception_ptr
>>>
>>> expected_or_error<T,E> // or whatever better name we find
>>>
>>> throws E
>>>
>> I'd rather just have a single excepted<T, E> and either always specify
>> throw or always specify UB. If I happen to be there for a poll for an
>> expected proposal where expected<T, E> always specifies throw, I would n=
ot
>> vote against it just because of that alone. The facility is very useful
>> regardless and the difference doesn't impact my uses enough. As long as =
the
>> template is consistent, I'm happy enough. I would, however, vote against
>> the proposal if it threw *only* when E is std::exception_ptr or is
>> otherwise determined to be an "exception" type.
>>
>> So, my thoughts are just 1 template that is consistent, regardless of
>> whether than means always specify throwing or always specifying UB.
>>
>>
> To match optional and variant, it isn't going to be UB. It is going to
> throw. The question is what should expected<Foo,int> throw? Should it
> just throw int? Or throw bad_expected_access<int> (similar to
> optional.value() which throws bad_optional_access).
> And then what should expected<Foo, exception_ptr> throw?
I believe that if we MUST throw always the same thing I will choose=20
bad_expected_access<E>.
>
> If you want UB, call operator*(). Same as optional; similar to vector[] =
vs
> vector.at().
>
Right, and already in the proposal :)
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 11 Nov 2015 14:36:13 -0800 (PST)
Raw View
------=_Part_1057_1124768435.1447281373324
Content-Type: multipart/alternative;
boundary="----=_Part_1058_1911832299.1447281373325"
------=_Part_1058_1911832299.1447281373325
Content-Type: text/plain; charset=UTF-8
On Wednesday, November 11, 2015 at 5:19:05 PM UTC-5, Tony V E wrote:
>
>
>
> On Wed, Nov 11, 2015 at 4:56 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> On Wed, Nov 11, 2015 at 1:36 PM, Vicente J. Botet Escriba <
>> vicent...@wanadoo.fr <javascript:>> wrote:
>>>
>>> Would you be against/for having two classes
>>>
>>> expected<T>
>>>
>>> throws the exception stored in the exception_ptr
>>>
>>> expected_or_error<T,E> // or whatever better name we find
>>>
>>> throws E
>>>
>>
>> I'd rather just have a single excepted<T, E> and either always specify
>> throw or always specify UB. If I happen to be there for a poll for an
>> expected proposal where expected<T, E> always specifies throw, I would not
>> vote against it just because of that alone. The facility is very useful
>> regardless and the difference doesn't impact my uses enough. As long as the
>> template is consistent, I'm happy enough. I would, however, vote against
>> the proposal if it threw *only* when E is std::exception_ptr or is
>> otherwise determined to be an "exception" type.
>>
>> So, my thoughts are just 1 template that is consistent, regardless of
>> whether than means always specify throwing or always specifying UB.
>>
>>
> To match optional and variant, it isn't going to be UB. It is going to
> throw. The question is what should expected<Foo,int> throw? Should it
> just throw int? Or throw bad_expected_access<int> (similar to
> optional.value() which throws bad_optional_access).
> And then what should expected<Foo, exception_ptr> throw?
>
Well, if there is a `bad_expected_access<E>`, then it should throw
`bad_expected_access<exception_ptr>`. It may seem a bit silly, but it is
very consistent.
Remember: the error is not that the expected had an error in it. The error
was that you didn't check for it. Personally, I don't think the exception
should carry the error object within it.
If you want UB, call operator*(). Same as optional; similar to vector[] vs
> vector.at().
>
That sounds good.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1058_1911832299.1447281373325
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, November 11, 2015 at 5:19:05 PM UTC-5, Tony V E wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br=
><div class=3D"gmail_quote">On Wed, Nov 11, 2015 at 4:56 PM, 'Matt Cala=
brese' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6gdsaKNKFw=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">std-pr.=
...@isocpp.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote"><span>On Wed, Nov 11, 2015 at 1=
:36 PM, Vicente J. Botet Escriba <span dir=3D"ltr"><<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"6gdsaKNKFwAJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">vicent...@wanadoo.fr</a=
>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" =
text=3D"#000000">
<font size=3D"+1">Would you be against/for having two classes<br>
<br>
expected<T> <br>
<br>
throws the exception stored in the exception_ptr<br>
<br>
expected_or_error<T,E> // or whatever better name we find<br>
<br>
</font><font size=3D"+1"><font size=3D"+1">throws E</font></font></div>=
</blockquote><div><br></div></span><div>I'd rather just have a single e=
xcepted<T, E> and either always specify throw or always specify UB. I=
f I happen to be there for a poll for an expected proposal where expected&l=
t;T, E> always specifies throw, I would not vote against it just because=
of that alone. The facility is very useful regardless and the difference d=
oesn't impact my uses enough. As long as the template is consistent, I&=
#39;m happy enough. I would, however, vote against the proposal if it threw=
*only* when E is std::exception_ptr or is otherwise determined to be an &q=
uot;exception" type.</div><div><br></div><div>So, my thoughts are just=
1 template that is consistent, regardless of whether than means always spe=
cify throwing or always specifying UB.</div></div><br></div></div></blockqu=
ote><div><br></div><div>To match optional and variant, it isn't going t=
o be UB.=C2=A0 It is going to throw.=C2=A0 The question is what should expe=
cted<Foo,int> throw?=C2=A0 Should it just throw int?=C2=A0 Or throw b=
ad_expected_access<int> (similar to optional.value() which throws bad=
_optional_access).<br></div><div>And then what should expected<Foo, exce=
ption_ptr> throw?<br></div></div></div></div></blockquote><div><br>Well,=
if there is a `bad_expected_access<E>`, then it should throw `bad_ex=
pected_access<exception_ptr>`. It may seem a bit silly, but it is ver=
y consistent.<br><br>Remember: the error is not that the expected had an er=
ror in it. The error was that you didn't check for it. Personally, I do=
n't think the exception should carry the error object within it.<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote"><div></div><div></div><div>If you want UB, call o=
perator*().=C2=A0 Same as optional; similar to vector[] vs <a href=3D"http:=
//vector.at" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fvector.at\46sa\75D\46sntz\0=
751\46usg\75AFQjCNElsVmWbw7Jl3n6Zza2D9GrnorMXg';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fvector.at\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNElsVmWbw7Jl3n6Zza2D9GrnorMXg';return =
true;">vector.at</a>().<br></div></div></div></div></blockquote><div><br>Th=
at sounds good.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1058_1911832299.1447281373325--
------=_Part_1057_1124768435.1447281373324--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 23:37:31 +0100
Raw View
Le 11/11/2015 23:25, Tony V E a =C3=A9crit :
> On Wed, Nov 11, 2015 at 4:27 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Le 11/11/2015 22:12, Tony V E a =C3=A9crit :
>>
>>> On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <
>>> vicente.botet@wanadoo.fr> wrote:
>>>
>>> Hi,
>>>>
>>>>
>>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>=
>
>>>>
>>>>
>>>> Not sure what I think of this, but I'll suggest it anyhow: make the
>>> traits
>>> into wrapper classes:
>>>
>>> 0. expected<T, E> // default: if E is exception or exception_ptr
>>> throw
>>> it, otherwise throw bad_access<E>
>>>
>>> 1. expected<T, as_error<Ex>> // even if Ex is an exception, treat i=
t
>>> like an error - ie always throw bad_access<Ex>
>>>
>>> 2. expected<T, as_exception<Err>> // even if Err is NOT an excepti=
on,
>>> always throw Err
>>>
>>>
>>> So really expected<T,E> looks for an expected-friendly interface on E
>>> (similar to your traits interface), and if it finds it, it uses it.
>>> Otherwise it uses its "magic" default behaviour. as_error<> and
>>> as_exception<> would be two common ways of building the expected-friend=
ly
>>> interface.
>>>
>>> Not sure if I like that any better. But it sort of lessens the weight =
for
>>> the average user.
>>>
>>> Are you proposing that expected is aware of as_error and as_exception?
>>
> Not exactly. It only appears that way. In reality, it would probably be
> that as_error<> and as_exception<> either both derive from
> expected_error_handler_interface or at least both implement the right
> member functions which are detected at compile time.
> So you could pass in your own E that happens to implement the correct
> interface, and we just happen to supply 2 common/useful examples.
>
> It's very similar to traits. Just sort or moves where/how the
> customization happens.
>
It would be difficult to describe what is the error and the exception=20
associated to expected<T,E>, isn't it?
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 11 Nov 2015 23:44:06 +0100
Raw View
This is a multi-part message in MIME format.
--------------040704040205090205030706
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/11/2015 22:21, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>> On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
>> Future Proposals <std-proposals@isocpp.org> wrote:
>>
>>> On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <calabrese@google.com>
>>> wrote:
>>>
>>>> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>>>> ie I was unsure about expected<T, E> working differently when E is an
>>>>> exception, vs when E is an int or any other error.
>>>>> Particularly since in C++, almost anything can be thrown as an
>>>>> exception. But we could define "is an exception" to be "derived from
>>>>> std::exception". Or is exception_ptr. Or...
>>>>>
>>>> This is my major gripe. I've implemented and used expected quite a bit=
,
>>>> based around the proposal, but I leave out the special handling for
>>>> exception_ptr. I strongly feel that it is a mistake.
>>>>
>>> To be clear, I don't think there should be special handling/change in
>>> behavior for "exceptions" being contained, not that std::exception_ptr =
was
>>> too specific. I think the behavior should be consistent regardless of
>>> whether or not E is assumed to be an exception.
>>>
>> to be clear, just throw bad_access<exception_ptr> and
>> bad_access<MyException> and bad_access<int> when those are the types of =
Es?
>>
> Ultimately being consistent is the most important thing to me here, but i=
n
> my opinion they should all *never* throw.
>
What is wrong by throwing system_error when the error is error_code?=20
Both classes have been designed to work together?
What is the advantage to throwing bad_expected_access<error_code>?
In which use cases bad_expected_access<error_code> it is better than=20
system_error?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------040704040205090205030706
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/11/2015 22:21, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CANh8DE=3DfTGTgeJq3g0dP+1hVzu_Xxn+aR=3DukK_REsD-SY_k9Sg@mail.gm=
ail.com"
type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <a class=3D"=
moz-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvaneerd@gmai=
l.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:std-prop=
osals@isocpp.org"><std-proposals@isocpp.org></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <a=
class=3D"moz-txt-link-rfc2396E" href=3D"mailto:calabrese@google.com"><c=
alabrese@google.com></a>
wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <a cl=
ass=3D"moz-txt-link-rfc2396E" href=3D"mailto:tvaneerd@gmail.com"><tvanee=
rd@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
ie I was unsure about expected<T, E> working differently when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an
exception. But we could define "is an exception" to be "derived from
std::exception". Or is exception_ptr. Or...
</pre>
</blockquote>
<pre wrap=3D"">
This is my major gripe. I've implemented and used expected quite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
</pre>
</blockquote>
<pre wrap=3D"">
To be clear, I don't think there should be special handling/change in
behavior for "exceptions" being contained, not that std::exception_ptr was
too specific. I think the behavior should be consistent regardless of
whether or not E is assumed to be an exception.
</pre>
</blockquote>
<pre wrap=3D"">
to be clear, just throw bad_access<exception_ptr> and
bad_access<MyException> and bad_access<int> when those are the =
types of Es?
</pre>
</blockquote>
<pre wrap=3D"">
Ultimately being consistent is the most important thing to me here, but in
my opinion they should all *never* throw.
</pre>
</blockquote>
<font size=3D"+1">What is wrong by throwing system_error when the
error is error_code? Both classes have been designed to work
together?<br>
What is the advantage to throwing
bad_expected_access<error_code>?<br>
In which use cases </font><font size=3D"+1"><font size=3D"+1">bad_exp=
ected_access<error_code></font>
it is better than system_error?<br>
<br>
Vicente<br>
<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------040704040205090205030706--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 17:53:00 -0500
Raw View
--001a114063ec310a6605244bb0b4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 5:44 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 11/11/2015 22:21, 'Matt Calabrese' via ISO C++ Standard - Future
> Proposals a =C3=A9crit :
>
> On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <tvaneerd@gmail.com> <tvaneerd@=
gmail.com> wrote:
>
>
> On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> <std-proposals@isocpp.org> wr=
ote:
>
>
> On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <calabrese@google.com> <c=
alabrese@google.com>
> wrote:
>
>
> On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <tvaneerd@gmail.com> <tvaneerd=
@gmail.com> wrote:
>
> ie I was unsure about expected<T, E> working differently when E is an
> exception, vs when E is an int or any other error.
> Particularly since in C++, almost anything can be thrown as an
> exception. But we could define "is an exception" to be "derived from
> std::exception". Or is exception_ptr. Or...
>
>
> This is my major gripe. I've implemented and used expected quite a bit,
> based around the proposal, but I leave out the special handling for
> exception_ptr. I strongly feel that it is a mistake.
>
>
> To be clear, I don't think there should be special handling/change in
> behavior for "exceptions" being contained, not that std::exception_ptr wa=
s
> too specific. I think the behavior should be consistent regardless of
> whether or not E is assumed to be an exception.
>
>
> to be clear, just throw bad_access<exception_ptr> and
> bad_access<MyException> and bad_access<int> when those are the types of E=
s?
>
>
> Ultimately being consistent is the most important thing to me here, but i=
n
> my opinion they should all *never* throw.
>
>
> What is wrong by throwing system_error when the error is error_code? Both
> classes have been designed to work together?
> What is the advantage to throwing bad_expected_access<error_code>?
> In which use cases bad_expected_access<error_code> it is better than
> system_error?
>
>
In general:
A Hammer is one of the best interfaces ever made. Everyone knows how it
works - you can pretty much tell just by looking at it. Even a 3 year old,
given a toy plastic hammer, will (mostly) hold it and use it correctly (and
also chew on it).
When you use a hammer with a screw instead of a nail, the hammer doesn't
become a screwdriver. It stays a hammer. Why do you want to use a hammer
on a screw? I don't know, but that's your decision, you probably have a
reason (ie tapping a screw with the hammer a few times to get it started
works well for wood-screws) and you should get what you expected.
And when the 3 year old puts the plastic hammer in their mouth, it tastes
like plastic, not chocolate.
Tony
> Vicente
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a114063ec310a6605244bb0b4
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 Wed, Nov 11, 2015 at 5:44 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
<div>Le 11/11/2015 22:21, 'Matt Calabrese'
via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<pre>On Wed, Nov 11, 2015 at 1:17 PM, Tony V E <a href=3D"mailto:tvan=
eerd@gmail.com" target=3D"_blank"><tvaneerd@gmail.com></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>On Wed, Nov 11, 2015 at 4:14 PM, 'Matt Calabrese' via =
ISO C++ Standard -
Future Proposals <a href=3D"mailto:std-proposals@isocpp.org" target=3D"_bla=
nk"><std-proposals@isocpp.org></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre>On Wed, Nov 11, 2015 at 1:08 PM, Matt Calabrese <a href=3D"m=
ailto:calabrese@google.com" target=3D"_blank"><calabrese@google.com><=
/a>
wrote:
</pre>
<blockquote type=3D"cite">
<pre>On Wed, Nov 11, 2015 at 12:52 PM, Tony V E <a href=3D"mail=
to:tvaneerd@gmail.com" target=3D"_blank"><tvaneerd@gmail.com></a> wro=
te:
</pre>
<blockquote type=3D"cite">
<pre>ie I was unsure about expected<T, E> working diffe=
rently when E is an
exception, vs when E is an int or any other error.
Particularly since in C++, almost anything can be thrown as an
exception. But we could define "is an exception" to be "der=
ived from
std::exception". Or is exception_ptr. Or...
</pre>
</blockquote>
<pre>This is my major gripe. I've implemented and used expe=
cted quite a bit,
based around the proposal, but I leave out the special handling for
exception_ptr. I strongly feel that it is a mistake.
</pre>
</blockquote>
<pre>To be clear, I don't think there should be special handl=
ing/change in
behavior for "exceptions" being contained, not that std::exceptio=
n_ptr was
too specific. I think the behavior should be consistent regardless of
whether or not E is assumed to be an exception.
</pre>
</blockquote>
<pre>to be clear, just throw bad_access<exception_ptr> and
bad_access<MyException> and bad_access<int> when those are the =
types of Es?
</pre>
</blockquote>
<pre>Ultimately being consistent is the most important thing to me he=
re, but in
my opinion they should all *never* throw.
</pre>
</blockquote>
</span><font size=3D"+1">What is wrong by throwing system_error when th=
e
error is error_code? Both classes have been designed to work
together?<br>
What is the advantage to throwing
bad_expected_access<error_code>?<br>
In which use cases </font><font size=3D"+1"><font size=3D"+1">bad_exp=
ected_access<error_code></font>
it is better than system_error?<span class=3D"HOEnZb"><font color=3D"=
#888888"><br>
<br></font></span></font></div></blockquote><div><br></div><div>In ge=
neral:<br><br></div><div>A Hammer is one of the best interfaces ever made.=
=C2=A0 Everyone knows how it works - you can pretty much tell just by looki=
ng at it.=C2=A0 Even a 3 year old, given a toy plastic hammer, will (mostly=
) hold it and use it correctly (and also chew on it).<br><br></div><div>Whe=
n you use a hammer with a screw instead of a nail, the hammer doesn't b=
ecome a screwdriver.=C2=A0 It stays a hammer.=C2=A0 Why do you want to use =
a hammer on a screw? I don't know, but that's your decision, you pr=
obably have a reason (ie tapping a screw with the hammer a few times to get=
it started works well for wood-screws) and you should get what you expecte=
d.<br><br></div><div>And when the 3 year old puts the plastic hammer in the=
ir mouth, it tastes like plastic, not chocolate.<br></div><div><br></div><d=
iv>Tony<br></div><div><br></div><div><br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><font size=3D"+1"><=
span class=3D"HOEnZb"><font color=3D"#888888">
Vicente<br>
<br>
</font></span></font>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a114063ec310a6605244bb0b4--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 11 Nov 2015 15:00:28 -0800 (PST)
Raw View
------=_Part_9113_1200210828.1447282828590
Content-Type: multipart/alternative;
boundary="----=_Part_9114_717620968.1447282828591"
------=_Part_9114_717620968.1447282828591
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :=20
> >=20
> > On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet=
=20
> > Escriba wrote:=20
> >> Hi,=20
> >>=20
> >> I would like to re-raise the expected discussion. Beside the=20
> conflicting=20
> >> part "managing errors in a different way", that should be covered by a=
=20
> >> specific paper, I would like to open the discussion in order to have a=
=20
> >> better proposal for expected.=20
> >>=20
> >> There were some concerns about the exception throw when there is no=20
> value.=20
> >> I'm wondering if we can do as for basic_string, we can have an=20
> error_traits=20
> >> that define which exception is thrown and that can also do conversion=
=20
> from=20
> >> exception to errors.=20
> >>=20
> > Here's my feeling on this.=20
> >=20
> > If you have some expected object and you do `.value` on it (or any of=
=20
> its=20
> > equivalents), what you are saying very clearly is this: I fully and=20
> > completely expect that this object will not be in the error state.=20
> That's=20
> > the conceptual precondition of your code.=20
> No. value is a wide interface. We could add a narrow dereference=20
> function if we think is useful.=20
> >=20
> > If that condition is violated, then the problem with your code is that=
=20
> the=20
> > condition was violated. That is, the problem with your code is not that=
=20
> a=20
> > function emitted an error of some type. It's that a function emitted an=
=20
> > error and *you didn't check it*. This is the same error no matter what=
=20
> the=20
> > error code type is, so it should throw the same exception from every=20
> > `expected` object.=20
> You reached to lost me. have you read the expected proposal?=20
> > That being said, I could see having a `throw_if_error` function, which=
=20
> will=20
> > throw an exception based on the error code if the expected object is in=
=20
> the=20
> > error state.=20
> Oh, I see that you have not, or you have forgotten the proposed interface=
?
>
The last expected proposal was over a year ago. I don't know why you would=
=20
expect everyone to be familiar with every aspect of its design.
That being said, why not have a `throw_if_error` function that actually=20
throws `E` (or throws the exception contained in an `exception_ptr`)?
=20
> >=20
> > Also, we don't want to overburden `expected` with customization=20
> machinery.=20
> > Not unless there's a really good reason. I don't want to have to hunt=
=20
> down=20
> > some traits class to see what I should have to catch. Throwing the erro=
r=20
> > code type itself, whatever that type is, should be sufficient for a=20
> > function like `throw_if_error`.=20
> Please, refer to the proposal. Do you mean that expected<T,E>::value()=20
> should throw an exception E?=20
> What about expected<T,exception_ptr>, should throw an exception_ptr?=20
>
> After all, I've always felt that the point of `expected` was to *not* use=
=20
> > exceptions, to have an alternative to them.=20
> Some could make this use, but expected works very well with exceptions.=
=20
> There is no either you use exceptions or you use expected decision to=20
> make.=20
>
But there is such a decision to make. I recall a discussion about this.
If `expected` holds an `exception_ptr`, then the only useful thing a user=
=20
can do with that is throw it. They can't test it. They can't print it. They=
=20
can only throw it and catch the result. That makes for a useless error code=
=20
value, so I seriously doubt anyone will use it as such.
In short, you're not going to see a lot of `expected<T, exception_ptr>`. It=
=20
just doesn't make sense. You may as well have just thrown the exception=20
directly. After all, the *only way* to create an `exception_ptr` is to=20
throw an exception, so you've already paid the price one time. There is=20
absolutely no reason to catch an exception, package it into an `expected<T,=
=20
exception_ptr>`, and then give it to someone who's *only useful option* is=
=20
to throw it again.
Throwing exceptions isn't cheap. That's a cost that needs to be paid at=20
most once.
If I'm writing a function that can fail, I can choose to signal that=20
failure in one of two ways: exception or expected. If I use `expected`,=20
then I have to choose what to return in the case of failure. Returning a=20
big object bloats the return value, so I have an incentive to minimize the=
=20
error data. And because the direct caller will be the one who handles it=20
(in all likelihood), he doesn't need to know much more than that the=20
operation failed. He doesn't need a string or a complex data structure=20
storing what happened. He knows exactly what he asked for, and he knows=20
exactly where it failed. All he needs to know is why.
If I throw an exception, I *must* assume that the person catching it may=20
have very little information about the particulars of the call that caused=
=20
it. Therefore, my exception must store a lot of data, so that the receiver=
=20
can know what to do with it.
Notice how the FileSystem TS's exception type holds rich data, while the=20
error code is just a number.
Emitting an exception is a heavy-weight operation, so making it slightly=20
heavier by returning rich data is fine. Returning an expected is a=20
light-weight operation, so making it heavier is a bad thing. We should not=
=20
confuse the two and try to treat expected as some kind of precursor to an=
=20
exception.
=20
> > It seems kinda silly to add a=20
> > customization point solely for exception behavior, when that's exactly=
=20
> what=20
> > you're trying to avoid.=20
> >=20
> It seems that you don't understand the purpose of expected.
I understand what *I want* from expected. You seem to think of it as some=
=20
functional programming gizmo or some way of passing exceptions around. For=
=20
me, it's an *alternative* mechanism of error reporting that is biased=20
towards local error handling rather than non-local handling.
=20
> If proposed=20
> expected is able to throw an exception when there is no value. That's it.=
=20
> The question is which exception.
>
And I said "it seems kinda silly to *add a customization point solely for=
=20
exception behavior*, when that's exactly what you're trying to avoid." So=
=20
on the matter of customizable exceptions, I say no.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_9114_717620968.1447282828591
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Botet Escri=
ba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 11/11/2015 21:29, =
Nicol Bolas a =C3=A9crit :
<br>>
<br>> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Bo=
tet
<br>> Escriba wrote:
<br>>> Hi,
<br>>>
<br>>> I would like to re-raise the expected discussion. Beside the c=
onflicting
<br>>> part "managing errors in a different way", that shou=
ld be covered by a
<br>>> specific paper, I would like to open the discussion in order t=
o have a
<br>>> better proposal for expected.
<br>>>
<br>>> There were some concerns about the exception throw when there =
is no value.
<br>>> I'm wondering if we can do as for basic_string, we can hav=
e an error_traits
<br>>> that define which exception is thrown and that can also do con=
version from
<br>>> exception to errors.
<br>>>
<br>> Here's my feeling on this.
<br>>
<br>> If you have some expected object and you do `.value` on it (or any=
of its
<br>> equivalents), what you are saying very clearly is this: I fully an=
d
<br>> completely expect that this object will not be in the error state.=
That's
<br>> the conceptual precondition of your code.
<br>No. value is a wide interface. We could add a narrow dereference=20
<br>function if we think is useful.
<br>>
<br>> If that condition is violated, then the problem with your code is =
that the
<br>> condition was violated. That is, the problem with your code is not=
that a
<br>> function emitted an error of some type. It's that a function e=
mitted an
<br>> error and *you didn't check it*. This is the same error no mat=
ter what the
<br>> error code type is, so it should throw the same exception from eve=
ry
<br>> `expected` object.
<br>You reached to lost me. have you read the expected proposal?
<br>> That being said, I could see having a `throw_if_error` function, w=
hich will
<br>> throw an exception based on the error code if the expected object =
is in the
<br>> error state.
<br>Oh, I see that you have not, or you have forgotten the proposed interfa=
ce?<br></blockquote><div><br>The last expected proposal was over a year ago=
.. I don't know why you would expect everyone to be familiar with every =
aspect of its design.<br><br>That being said, why not have a `throw_if_erro=
r` function that actually throws `E` (or throws the exception contained in =
an `exception_ptr`)?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">>
<br>> Also, we don't want to overburden `expected` with customizatio=
n machinery.
<br>> Not unless there's a really good reason. I don't want to h=
ave to hunt down
<br>> some traits class to see what I should have to catch. Throwing the=
error
<br>> code type itself, whatever that type is, should be sufficient for =
a
<br>> function like `throw_if_error`.
<br>Please, refer to the proposal. Do you mean that expected<T,E>::va=
lue()=20
<br>should throw an exception E?
<br>What about expected<T,exception_ptr>, should throw an exception_p=
tr?
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> After al=
l, I've always felt that the point of `expected` was to *not* use
<br>> exceptions, to have an alternative to them.
<br>Some could make this use, but expected works very well with exceptions.=
=20
<br>There is no either you use exceptions or you use expected decision to m=
ake.
<br></blockquote><div><br>But there is such a decision to make. I recall a =
discussion about this.<br><br>If `expected` holds an `exception_ptr`, then =
the only useful thing a user can do with that is throw it. They can't t=
est it. They can't print it. They can only throw it and catch the resul=
t. That makes for a useless error code value, so I seriously doubt anyone w=
ill use it as such.<br><br>In short, you're not going to see a lot of `=
expected<T, exception_ptr>`. It just doesn't make sense. You may =
as well have just thrown the exception directly. After all, the <i>only way=
</i> to create an `exception_ptr` is to throw an exception, so you've a=
lready paid the price one time. There is absolutely no reason to catch an e=
xception, package it into an `expected<T, exception_ptr>`, and then g=
ive it to someone who's <i>only useful option</i> is to throw it again.=
<br><br>Throwing exceptions isn't cheap. That's a cost that needs t=
o be paid at most once.<br><br>If I'm writing a function that can fail,=
I can choose to signal that failure in one of two ways: exception or expec=
ted. If I use `expected`, then I have to choose what to return in the case =
of failure. Returning a big object bloats the return value, so I have an in=
centive to minimize the error data. And because the direct caller will be t=
he one who handles it (in all likelihood), he doesn't need to know much=
more than that the operation failed. He doesn't need a string or a com=
plex data structure storing what happened. He knows exactly what he asked f=
or, and he knows exactly where it failed. All he needs to know is why.<br><=
br>If I throw an exception, I <i>must</i> assume that the person catching i=
t may have very little information about the particulars of the call that c=
aused it. Therefore, my exception must store a lot of data, so that the rec=
eiver can know what to do with it.<br><br>Notice how the FileSystem TS'=
s exception type holds rich data, while the error code is just a number.<br=
><br>Emitting an exception is a heavy-weight operation, so making it slight=
ly heavier by returning rich data is fine. Returning an expected is a light=
-weight operation, so making it heavier is a bad thing. We should not confu=
se the two and try to treat expected as some kind of precursor to an except=
ion.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> I=
t seems kinda silly to add a
<br>> customization point solely for exception behavior, when that's=
exactly what
<br>> you're trying to avoid.
<br>>
<br>It seems that you don't understand the purpose of expected.</blockq=
uote><div><br>I understand what <i>I want</i> from expected. You seem to th=
ink of it as some functional programming gizmo or some way of passing excep=
tions around. For me, it's an <i>alternative</i> mechanism of error rep=
orting that is biased towards local error handling rather than non-local ha=
ndling.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If prop=
osed=20
<br>expected is able to throw an exception when there is no value. That'=
;s it.
<br>The question is which exception.<br></blockquote><div><br>And I said &q=
uot;it seems kinda silly to <u>add a customization point solely for excepti=
on behavior</u>, when that's exactly what you're trying to avoid.&q=
uot; So on the matter of customizable exceptions, I say no.<u> </u><br></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9114_717620968.1447282828591--
------=_Part_9113_1200210828.1447282828590--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 18:10:05 -0500
Raw View
--001a113fb8ea4e031305244bedf8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 6:00 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>>
>> Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :
>> >
>> > On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet
>> > Escriba wrote:
>> >> Hi,
>> >>
>> >> I would like to re-raise the expected discussion. Beside the
>> conflicting
>> >> part "managing errors in a different way", that should be covered by =
a
>> >> specific paper, I would like to open the discussion in order to have =
a
>> >> better proposal for expected.
>> >>
>> >> There were some concerns about the exception throw when there is no
>> value.
>> >> I'm wondering if we can do as for basic_string, we can have an
>> error_traits
>> >> that define which exception is thrown and that can also do conversion
>> from
>> >> exception to errors.
>> >>
>> > Here's my feeling on this.
>> >
>> > If you have some expected object and you do `.value` on it (or any of
>> its
>> > equivalents), what you are saying very clearly is this: I fully and
>> > completely expect that this object will not be in the error state.
>> That's
>> > the conceptual precondition of your code.
>> No. value is a wide interface. We could add a narrow dereference
>> function if we think is useful.
>> >
>> > If that condition is violated, then the problem with your code is that
>> the
>> > condition was violated. That is, the problem with your code is not tha=
t
>> a
>> > function emitted an error of some type. It's that a function emitted a=
n
>> > error and *you didn't check it*. This is the same error no matter what
>> the
>> > error code type is, so it should throw the same exception from every
>> > `expected` object.
>> You reached to lost me. have you read the expected proposal?
>> > That being said, I could see having a `throw_if_error` function, which
>> will
>> > throw an exception based on the error code if the expected object is i=
n
>> the
>> > error state.
>> Oh, I see that you have not, or you have forgotten the proposed interfac=
e?
>>
>
> The last expected proposal was over a year ago. I don't know why you woul=
d
> expect everyone to be familiar with every aspect of its design.
>
> That being said, why not have a `throw_if_error` function that actually
> throws `E` (or throws the exception contained in an `exception_ptr`)?
>
>
>> >
>> > Also, we don't want to overburden `expected` with customization
>> machinery.
>> > Not unless there's a really good reason. I don't want to have to hunt
>> down
>> > some traits class to see what I should have to catch. Throwing the
>> error
>> > code type itself, whatever that type is, should be sufficient for a
>> > function like `throw_if_error`.
>> Please, refer to the proposal. Do you mean that expected<T,E>::value()
>> should throw an exception E?
>> What about expected<T,exception_ptr>, should throw an exception_ptr?
>>
> > After all, I've always felt that the point of `expected` was to *not*
>> use
>> > exceptions, to have an alternative to them.
>> Some could make this use, but expected works very well with exceptions.
>> There is no either you use exceptions or you use expected decision to
>> make.
>>
>
> But there is such a decision to make. I recall a discussion about this.
>
> If `expected` holds an `exception_ptr`, then the only useful thing a user
> can do with that is throw it. They can't test it. They can't print it. Th=
ey
> can only throw it and catch the result. That makes for a useless error co=
de
> value, so I seriously doubt anyone will use it as such.
>
> In short, you're not going to see a lot of `expected<T, exception_ptr>`.
> It just doesn't make sense. You may as well have just thrown the exceptio=
n
> directly. After all, the *only way* to create an `exception_ptr` is to
> throw an exception, so you've already paid the price one time.
>
std::make_exception_ptr().
Of course, it may be implemented via try-throw-catch. Or it may not.
I do NOT think that makes your argument moot, however.
> There is absolutely no reason to catch an exception, package it into an
> `expected<T, exception_ptr>`, and then give it to someone who's *only
> useful option* is to throw it again.
>
> Throwing exceptions isn't cheap. That's a cost that needs to be paid at
> most once.
>
> If I'm writing a function that can fail, I can choose to signal that
> failure in one of two ways: exception or expected. If I use `expected`,
> then I have to choose what to return in the case of failure. Returning a
> big object bloats the return value, so I have an incentive to minimize th=
e
> error data. And because the direct caller will be the one who handles it
> (in all likelihood), he doesn't need to know much more than that the
> operation failed. He doesn't need a string or a complex data structure
> storing what happened. He knows exactly what he asked for, and he knows
> exactly where it failed. All he needs to know is why.
>
> If I throw an exception, I *must* assume that the person catching it may
> have very little information about the particulars of the call that cause=
d
> it. Therefore, my exception must store a lot of data, so that the receive=
r
> can know what to do with it.
>
> Notice how the FileSystem TS's exception type holds rich data, while the
> error code is just a number.
>
> Emitting an exception is a heavy-weight operation, so making it slightly
> heavier by returning rich data is fine. Returning an expected is a
> light-weight operation, so making it heavier is a bad thing. We should no=
t
> confuse the two and try to treat expected as some kind of precursor to an
> exception.
>
>
>> > It seems kinda silly to add a
>> > customization point solely for exception behavior, when that's exactly
>> what
>> > you're trying to avoid.
>> >
>> It seems that you don't understand the purpose of expected.
>
>
> I understand what *I want* from expected. You seem to think of it as some
> functional programming gizmo or some way of passing exceptions around. Fo=
r
> me, it's an *alternative* mechanism of error reporting that is biased
> towards local error handling rather than non-local handling.
>
>
>> If proposed
>> expected is able to throw an exception when there is no value. That's it=
..
>> The question is which exception.
>>
>
> And I said "it seems kinda silly to *add a customization point solely for
> exception behavior*, when that's exactly what you're trying to avoid." So
> on the matter of customizable exceptions, I say no.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a113fb8ea4e031305244bedf8
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 Wed, Nov 11, 2015 at 6:00 PM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"=
><div class=3D"h5">On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vic=
ente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le 11/1=
1/2015 21:29, Nicol Bolas a =C3=A9crit :
<br>>
<br>> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Bo=
tet
<br>> Escriba wrote:
<br>>> Hi,
<br>>>
<br>>> I would like to re-raise the expected discussion. Beside the c=
onflicting
<br>>> part "managing errors in a different way", that shou=
ld be covered by a
<br>>> specific paper, I would like to open the discussion in order t=
o have a
<br>>> better proposal for expected.
<br>>>
<br>>> There were some concerns about the exception throw when there =
is no value.
<br>>> I'm wondering if we can do as for basic_string, we can hav=
e an error_traits
<br>>> that define which exception is thrown and that can also do con=
version from
<br>>> exception to errors.
<br>>>
<br>> Here's my feeling on this.
<br>>
<br>> If you have some expected object and you do `.value` on it (or any=
of its
<br>> equivalents), what you are saying very clearly is this: I fully an=
d
<br>> completely expect that this object will not be in the error state.=
That's
<br>> the conceptual precondition of your code.
<br>No. value is a wide interface. We could add a narrow dereference=20
<br>function if we think is useful.
<br>>
<br>> If that condition is violated, then the problem with your code is =
that the
<br>> condition was violated. That is, the problem with your code is not=
that a
<br>> function emitted an error of some type. It's that a function e=
mitted an
<br>> error and *you didn't check it*. This is the same error no mat=
ter what the
<br>> error code type is, so it should throw the same exception from eve=
ry
<br>> `expected` object.
<br>You reached to lost me. have you read the expected proposal?
<br>> That being said, I could see having a `throw_if_error` function, w=
hich will
<br>> throw an exception based on the error code if the expected object =
is in the
<br>> error state.
<br>Oh, I see that you have not, or you have forgotten the proposed interfa=
ce?<br></blockquote></div></div><div><br>The last expected proposal was ove=
r a year ago. I don't know why you would expect everyone to be familiar=
with every aspect of its design.<br><br>That being said, why not have a `t=
hrow_if_error` function that actually throws `E` (or throws the exception c=
ontained in an `exception_ptr`)?<br>=C2=A0</div><span class=3D""><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex">>
<br>> Also, we don't want to overburden `expected` with customizatio=
n machinery.
<br>> Not unless there's a really good reason. I don't want to h=
ave to hunt down
<br>> some traits class to see what I should have to catch. Throwing the=
error
<br>> code type itself, whatever that type is, should be sufficient for =
a
<br>> function like `throw_if_error`.
<br>Please, refer to the proposal. Do you mean that expected<T,E>::va=
lue()=20
<br>should throw an exception E?
<br>What about expected<T,exception_ptr>, should throw an exception_p=
tr?
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> After all, I&=
#39;ve always felt that the point of `expected` was to *not* use
<br>> exceptions, to have an alternative to them.
<br>Some could make this use, but expected works very well with exceptions.=
=20
<br>There is no either you use exceptions or you use expected decision to m=
ake.
<br></blockquote></span><div><br>But there is such a decision to make. I re=
call a discussion about this.<br><br>If `expected` holds an `exception_ptr`=
, then the only useful thing a user can do with that is throw it. They can&=
#39;t test it. They can't print it. They can only throw it and catch th=
e result. That makes for a useless error code value, so I seriously doubt a=
nyone will use it as such.<br><br>In short, you're not going to see a l=
ot of `expected<T, exception_ptr>`. It just doesn't make sense. Y=
ou may as well have just thrown the exception directly. After all, the <i>o=
nly way</i> to create an `exception_ptr` is to throw an exception, so you&#=
39;ve already paid the price one time.</div></blockquote><div><br></div><di=
v>std::make_exception_ptr().<br><br></div><div>Of course, it may be impleme=
nted via try-throw-catch.=C2=A0 Or it may not.<br><br></div><div>I do NOT t=
hink that makes your argument moot, however.<br><br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div> There is absolutely no reason to catch=
an exception, package it into an `expected<T, exception_ptr>`, and t=
hen give it to someone who's <i>only useful option</i> is to throw it a=
gain.<br><br>Throwing exceptions isn't cheap. That's a cost that ne=
eds to be paid at most once.<br><br>If I'm writing a function that can =
fail, I can choose to signal that failure in one of two ways: exception or =
expected. If I use `expected`, then I have to choose what to return in the =
case of failure. Returning a big object bloats the return value, so I have =
an incentive to minimize the error data. And because the direct caller will=
be the one who handles it (in all likelihood), he doesn't need to know=
much more than that the operation failed. He doesn't need a string or =
a complex data structure storing what happened. He knows exactly what he as=
ked for, and he knows exactly where it failed. All he needs to know is why.=
<br><br>If I throw an exception, I <i>must</i> assume that the person catch=
ing it may have very little information about the particulars of the call t=
hat caused it. Therefore, my exception must store a lot of data, so that th=
e receiver can know what to do with it.<br><br>Notice how the FileSystem TS=
's exception type holds rich data, while the error code is just a numbe=
r.<br><br>Emitting an exception is a heavy-weight operation, so making it s=
lightly heavier by returning rich data is fine. Returning an expected is a =
light-weight operation, so making it heavier is a bad thing. We should not =
confuse the two and try to treat expected as some kind of precursor to an e=
xception.<br>=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">> It seems kinda silly to add a
<br>> customization point solely for exception behavior, when that's=
exactly what
<br>> you're trying to avoid.
<br>>
<br>It seems that you don't understand the purpose of expected.</blockq=
uote></span><div><br>I understand what <i>I want</i> from expected. You see=
m to think of it as some functional programming gizmo or some way of passin=
g exceptions around. For me, it's an <i>alternative</i> mechanism of er=
ror reporting that is biased towards local error handling rather than non-l=
ocal handling.<br>=C2=A0</div><span class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">If proposed=20
<br>expected is able to throw an exception when there is no value. That'=
;s it.
<br>The question is which exception.<br></blockquote></span><div><br>And I =
said "it seems kinda silly to <u>add a customization point solely for =
exception behavior</u>, when that's exactly what you're trying to a=
void." So on the matter of customizable exceptions, I say no.<u> </u><=
br></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113fb8ea4e031305244bedf8--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Nov 2015 18:14:05 -0500
Raw View
--047d7b3a82909324d605244bfbcc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2015 at 5:37 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 11/11/2015 23:25, Tony V E a =C3=A9crit :
>
>> On Wed, Nov 11, 2015 at 4:27 PM, Vicente J. Botet Escriba <
>> vicente.botet@wanadoo.fr> wrote:
>>
>> Le 11/11/2015 22:12, Tony V E a =C3=A9crit :
>>>
>>> On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <
>>>> vicente.botet@wanadoo.fr> wrote:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>>
>>>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error=
>>
>>>>>
>>>>>
>>>>> Not sure what I think of this, but I'll suggest it anyhow: make the
>>>>>
>>>> traits
>>>> into wrapper classes:
>>>>
>>>> 0. expected<T, E> // default: if E is exception or exception_ptr
>>>> throw
>>>> it, otherwise throw bad_access<E>
>>>>
>>>> 1. expected<T, as_error<Ex>> // even if Ex is an exception, treat =
it
>>>> like an error - ie always throw bad_access<Ex>
>>>>
>>>> 2. expected<T, as_exception<Err>> // even if Err is NOT an
>>>> exception,
>>>> always throw Err
>>>>
>>>>
>>>> So really expected<T,E> looks for an expected-friendly interface on E
>>>> (similar to your traits interface), and if it finds it, it uses it.
>>>> Otherwise it uses its "magic" default behaviour. as_error<> and
>>>> as_exception<> would be two common ways of building the
>>>> expected-friendly
>>>> interface.
>>>>
>>>> Not sure if I like that any better. But it sort of lessens the weight
>>>> for
>>>> the average user.
>>>>
>>>> Are you proposing that expected is aware of as_error and as_exception?
>>>>
>>>
>>> Not exactly. It only appears that way. In reality, it would probably =
be
>> that as_error<> and as_exception<> either both derive from
>> expected_error_handler_interface or at least both implement the right
>> member functions which are detected at compile time.
>> So you could pass in your own E that happens to implement the correct
>> interface, and we just happen to supply 2 common/useful examples.
>>
>> It's very similar to traits. Just sort or moves where/how the
>> customization happens.
>>
>> It would be difficult to describe what is the error and the exception
> associated to expected<T,E>, isn't it?
Probably. If could be something like "if E has a nested type
E::expected_error... otherwise if E is std::error_code... otherwise the
error is E"
Or something like that.
I'm still not saying it is a good idea, just an idea that I think is worth
considering.
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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b3a82909324d605244bfbcc
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 Wed, Nov 11, 2015 at 5:37 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">Le 11/11/2015 23:25, Tony V E a =C3=A9crit :<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On Wed, Nov 11, 2015 at 4:27 PM, Vicente J. Botet Escriba <<br>
<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet=
@wanadoo.fr</a>> wrote:<br>
<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
Le 11/11/2015 22:12, Tony V E a =C3=A9crit :<br>
<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <<br>
<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet=
@wanadoo.fr</a>> wrote:<br>
<br>
Hi,<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<br>
<br><div><div class=3D"h5">
basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error=
>><br>
<br>
<br>
Not sure what I think of this, but I'll suggest it anyhow: make the<br>
</div></div></blockquote><div><div class=3D"h5">
traits<br>
into wrapper classes:<br>
<br>
0.=C2=A0 =C2=A0 expected<T, E>=C2=A0 =C2=A0// default: if E is except=
ion or exception_ptr<br>
throw<br>
it, otherwise throw bad_access<E><br>
<br>
1.=C2=A0 =C2=A0 expected<T, as_error<Ex>>=C2=A0 // even if Ex i=
s an exception, treat it<br>
like an error - ie always throw bad_access<Ex><br>
<br>
2.=C2=A0 =C2=A0 expected<T, as_exception<Err>>=C2=A0 =C2=A0// e=
ven if Err is NOT an exception,<br>
always throw Err<br>
<br>
<br>
So really expected<T,E> looks for an expected-friendly interface on E=
<br>
(similar to your traits interface), and if it finds it, it uses it.<br>
Otherwise it uses its "magic" default behaviour.=C2=A0 as_error&l=
t;> and<br>
as_exception<> would be two common ways of building the expected-frie=
ndly<br>
interface.<br>
<br>
Not sure if I like that any better.=C2=A0 But it sort of lessens the weight=
for<br>
the average user.<br>
<br>
Are you proposing that expected is aware of as_error and as_exception?<br>
</div></div></blockquote>
<br>
</blockquote><div><div class=3D"h5">
Not exactly.=C2=A0 It only appears that way.=C2=A0 In reality, it would pro=
bably be<br>
that as_error<> and as_exception<> either both derive from<br>
expected_error_handler_interface or at least both implement the right<br>
member functions which are detected at compile time.<br>
So you could pass in your own E that happens to implement the correct<br>
interface, and we just happen to supply 2 common/useful examples.<br>
<br>
It's very similar to traits.=C2=A0 Just sort or moves where/how the<br>
customization happens.<br>
<br>
</div></div></blockquote>
It would be difficult to describe what is the error and the exception assoc=
iated to expected<T,E>, isn't it?</blockquote><div><br></div><div=
>Probably.=C2=A0 If could be something like "if E has a nested type E:=
:expected_error... otherwise if E is std::error_code... otherwise the error=
is E"<br></div><div>Or something like that.<br><br></div><div>I'm=
still not saying it is a good idea, just an idea that I think is worth con=
sidering.<br><br></div><div>Tony<br><br></div><div><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 class=3D"HOEnZb"><div class=3D"h5"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b3a82909324d605244bfbcc--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 00:19:01 +0100
Raw View
Le 12/11/2015 00:00, Nicol Bolas a =C3=A9crit :
> On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :
>>> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet
>>> Escriba wrote:
>>>> Hi,
>>>>
>>>> I would like to re-raise the expected discussion. Beside the
>> conflicting
>>>> part "managing errors in a different way", that should be covered by a
>>>> specific paper, I would like to open the discussion in order to have a
>>>> better proposal for expected.
>>>>
>>>> There were some concerns about the exception throw when there is no
>> value.
>>>> I'm wondering if we can do as for basic_string, we can have an
>> error_traits
>>>> that define which exception is thrown and that can also do conversion
>> from
>>>> exception to errors.
>>>>
>>> Here's my feeling on this.
>>>
>>> If you have some expected object and you do `.value` on it (or any of
>> its
>>> equivalents), what you are saying very clearly is this: I fully and
>>> completely expect that this object will not be in the error state.
>> That's
>>> the conceptual precondition of your code.
>> No. value is a wide interface. We could add a narrow dereference
>> function if we think is useful.
>>> If that condition is violated, then the problem with your code is that
>> the
>>> condition was violated. That is, the problem with your code is not that
>> a
>>> function emitted an error of some type. It's that a function emitted an
>>> error and *you didn't check it*. This is the same error no matter what
>> the
>>> error code type is, so it should throw the same exception from every
>>> `expected` object.
>> You reached to lost me. have you read the expected proposal?
>>> That being said, I could see having a `throw_if_error` function, which
>> will
>>> throw an exception based on the error code if the expected object is in
>> the
>>> error state.
>> Oh, I see that you have not, or you have forgotten the proposed interfac=
e?
>>
> The last expected proposal was over a year ago. I don't know why you woul=
d
> expect everyone to be familiar with every aspect of its design.
>
> That being said, why not have a `throw_if_error` function that actually
> throws `E` (or throws the exception contained in an `exception_ptr`)?
We have already it value().
> =20
>
>>> Also, we don't want to overburden `expected` with customization
>> machinery.
>>> Not unless there's a really good reason. I don't want to have to hunt
>> down
>>> some traits class to see what I should have to catch. Throwing the erro=
r
>>> code type itself, whatever that type is, should be sufficient for a
>>> function like `throw_if_error`.
>> Please, refer to the proposal. Do you mean that expected<T,E>::value()
>> should throw an exception E?
>> What about expected<T,exception_ptr>, should throw an exception_ptr?
>>
>> After all, I've always felt that the point of `expected` was to *not* us=
e
>>> exceptions, to have an alternative to them.
>> Some could make this use, but expected works very well with exceptions.
>> There is no either you use exceptions or you use expected decision to
>> make.
>>
> But there is such a decision to make. I recall a discussion about this.
>
> If `expected` holds an `exception_ptr`, then the only useful thing a user
> can do with that is throw it. They can't test it. They can't print it. Th=
ey
> can only throw it and catch the result. That makes for a useless error co=
de
> value, so I seriously doubt anyone will use it as such.
I will use it as the underlying type for future e.g.
>
> In short, you're not going to see a lot of `expected<T, exception_ptr>`. =
It
> just doesn't make sense. You may as well have just thrown the exception
> directly. After all, the *only way* to create an `exception_ptr` is to
> throw an exception, so you've already paid the price one time. There is
> absolutely no reason to catch an exception, package it into an `expected<=
T,
> exception_ptr>`, and then give it to someone who's *only useful option* i=
s
> to throw it again.
There are other worlds where we want to use it.
>
> Throwing exceptions isn't cheap. That's a cost that needs to be paid at
> most once.
Not if the exception was already thrown independently of whether you=20
will store it in expected or rethrow it.
>
> If I'm writing a function that can fail, I can choose to signal that
> failure in one of two ways: exception or expected. If I use `expected`,
> then I have to choose what to return in the case of failure. Returning a
> big object bloats the return value, so I have an incentive to minimize th=
e
> error data. And because the direct caller will be the one who handles it
> (in all likelihood), he doesn't need to know much more than that the
> operation failed. He doesn't need a string or a complex data structure
> storing what happened. He knows exactly what he asked for, and he knows
> exactly where it failed. All he needs to know is why.
Function that return expected can call other functions that throw=20
exceptions, isn't it?
>
> If I throw an exception, I *must* assume that the person catching it may
> have very little information about the particulars of the call that cause=
d
> it. Therefore, my exception must store a lot of data, so that the receive=
r
> can know what to do with it.
>
> Notice how the FileSystem TS's exception type holds rich data, while the
> error code is just a number.
>
> Emitting an exception is a heavy-weight operation, so making it slightly
> heavier by returning rich data is fine. Returning an expected is a
> light-weight operation, so making it heavier is a bad thing. We should no=
t
> confuse the two and try to treat expected as some kind of precursor to an
> exception.
I don't believe I'm confusing the two?
> =20
>
>>> It seems kinda silly to add a
>>> customization point solely for exception behavior, when that's exactly
>> what
>>> you're trying to avoid.
>>>
>> It seems that you don't understand the purpose of expected.
>
> I understand what *I want* from expected.
If you know what you want, the best we can do is to write a proposal ;-)
> You seem to think of it as some
> functional programming gizmo or some way of passing exceptions around. Fo=
r
> me, it's an *alternative* mechanism of error reporting that is biased
> towards local error handling rather than non-local handling.
You are right, expected is a error reporting mechanism that needs local=20
error handling. However the await proposal gives him a transparent=20
non-local erro reporting. Since the original proposal there was some=20
kind of do-notation that simplified the error reporting. Now we ave=20
await :)
> =20
>
>> If proposed
>> expected is able to throw an exception when there is no value. That's it=
..
>> The question is which exception.
>>
> And I said "it seems kinda silly to *add a customization point solely for
> exception behavior*, when that's exactly what you're trying to avoid." So
> on the matter of customizable exceptions, I say no.
>
It is the fist time someone has said that. Now you and Mat say that we=20
don't need to throw any exception. Well, maybe you are right, maybe not.
This is what many other were requesting long time ago. This and many=20
more. Things can change of course.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 00:22:13 +0100
Raw View
Le 11/11/2015 23:53, Tony V E a =C3=A9crit :
> On Wed, Nov 11, 2015 at 5:44 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>>
>> What is wrong by throwing system_error when the error is error_code? Bot=
h
>> classes have been designed to work together?
>> What is the advantage to throwing bad_expected_access<error_code>?
>> In which use cases bad_expected_access<error_code> it is better than
>> system_error?
>>
>>
> In general:
>
> A Hammer is one of the best interfaces ever made. Everyone knows how it
> works - you can pretty much tell just by looking at it. Even a 3 year ol=
d,
> given a toy plastic hammer, will (mostly) hold it and use it correctly (a=
nd
> also chew on it).
>
> When you use a hammer with a screw instead of a nail, the hammer doesn't
> become a screwdriver. It stays a hammer. Why do you want to use a hamme=
r
> on a screw? I don't know, but that's your decision, you probably have a
> reason (ie tapping a screw with the hammer a few times to get it started
> works well for wood-screws) and you should get what you expected.
>
> And when the 3 year old puts the plastic hammer in their mouth, it tastes
> like plastic, not chocolate.
>
>
Lol,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 11 Nov 2015 15:23:00 -0800 (PST)
Raw View
------=_Part_9026_205876576.1447284180348
Content-Type: multipart/alternative;
boundary="----=_Part_9027_1219798437.1447284180348"
------=_Part_9027_1219798437.1447284180348
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 11, 2015 at 6:10:08 PM UTC-5, Tony V E wrote:
>
>
>
> On Wed, Nov 11, 2015 at 6:00 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Botet=20
>> Escriba wrote:
>>>
>>> Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :=20
>>> >=20
>>> > On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet=
=20
>>> > Escriba wrote:=20
>>> >> Hi,=20
>>> >>=20
>>> >> I would like to re-raise the expected discussion. Beside the=20
>>> conflicting=20
>>> >> part "managing errors in a different way", that should be covered by=
=20
>>> a=20
>>> >> specific paper, I would like to open the discussion in order to have=
=20
>>> a=20
>>> >> better proposal for expected.=20
>>> >>=20
>>> >> There were some concerns about the exception throw when there is no=
=20
>>> value.=20
>>> >> I'm wondering if we can do as for basic_string, we can have an=20
>>> error_traits=20
>>> >> that define which exception is thrown and that can also do conversio=
n=20
>>> from=20
>>> >> exception to errors.=20
>>> >>=20
>>> > Here's my feeling on this.=20
>>> >=20
>>> > If you have some expected object and you do `.value` on it (or any of=
=20
>>> its=20
>>> > equivalents), what you are saying very clearly is this: I fully and=
=20
>>> > completely expect that this object will not be in the error state.=20
>>> That's=20
>>> > the conceptual precondition of your code.=20
>>> No. value is a wide interface. We could add a narrow dereference=20
>>> function if we think is useful.=20
>>> >=20
>>> > If that condition is violated, then the problem with your code is tha=
t=20
>>> the=20
>>> > condition was violated. That is, the problem with your code is not=20
>>> that a=20
>>> > function emitted an error of some type. It's that a function emitted=
=20
>>> an=20
>>> > error and *you didn't check it*. This is the same error no matter wha=
t=20
>>> the=20
>>> > error code type is, so it should throw the same exception from every=
=20
>>> > `expected` object.=20
>>> You reached to lost me. have you read the expected proposal?=20
>>> > That being said, I could see having a `throw_if_error` function, whic=
h=20
>>> will=20
>>> > throw an exception based on the error code if the expected object is=
=20
>>> in the=20
>>> > error state.=20
>>> Oh, I see that you have not, or you have forgotten the proposed=20
>>> interface?
>>>
>>
>> The last expected proposal was over a year ago. I don't know why you=20
>> would expect everyone to be familiar with every aspect of its design.
>>
>> That being said, why not have a `throw_if_error` function that actually=
=20
>> throws `E` (or throws the exception contained in an `exception_ptr`)?
>> =20
>>
>>> >=20
>>> > Also, we don't want to overburden `expected` with customization=20
>>> machinery.=20
>>> > Not unless there's a really good reason. I don't want to have to hunt=
=20
>>> down=20
>>> > some traits class to see what I should have to catch. Throwing the=20
>>> error=20
>>> > code type itself, whatever that type is, should be sufficient for a=
=20
>>> > function like `throw_if_error`.=20
>>> Please, refer to the proposal. Do you mean that expected<T,E>::value()=
=20
>>> should throw an exception E?=20
>>> What about expected<T,exception_ptr>, should throw an exception_ptr?=20
>>>
>> > After all, I've always felt that the point of `expected` was to *not*=
=20
>>> use=20
>>> > exceptions, to have an alternative to them.=20
>>> Some could make this use, but expected works very well with exceptions.=
=20
>>> There is no either you use exceptions or you use expected decision to=
=20
>>> make.=20
>>>
>>
>> But there is such a decision to make. I recall a discussion about this.
>>
>> If `expected` holds an `exception_ptr`, then the only useful thing a use=
r=20
>> can do with that is throw it. They can't test it. They can't print it. T=
hey=20
>> can only throw it and catch the result. That makes for a useless error c=
ode=20
>> value, so I seriously doubt anyone will use it as such.
>>
>> In short, you're not going to see a lot of `expected<T, exception_ptr>`.=
=20
>> It just doesn't make sense. You may as well have just thrown the excepti=
on=20
>> directly. After all, the *only way* to create an `exception_ptr` is to=
=20
>> throw an exception, so you've already paid the price one time.
>>
>
> std::make_exception_ptr().
>
I don't know why I thought that was from a proposal someone made. Maybe it=
=20
was for a perfect forwarding version...
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_9027_1219798437.1447284180348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, November 11, 2015 at 6:10:08 PM UTC-5, Tony V E wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br=
><div class=3D"gmail_quote">On Wed, Nov 11, 2015 at 6:00 PM, Nicol Bolas <s=
pan dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"H570gGxNFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div>On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5=
, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le=
11/11/2015 21:29, Nicol Bolas a =C3=A9crit :
<br>>
<br>> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Bo=
tet
<br>> Escriba wrote:
<br>>> Hi,
<br>>>
<br>>> I would like to re-raise the expected discussion. Beside the c=
onflicting
<br>>> part "managing errors in a different way", that shou=
ld be covered by a
<br>>> specific paper, I would like to open the discussion in order t=
o have a
<br>>> better proposal for expected.
<br>>>
<br>>> There were some concerns about the exception throw when there =
is no value.
<br>>> I'm wondering if we can do as for basic_string, we can hav=
e an error_traits
<br>>> that define which exception is thrown and that can also do con=
version from
<br>>> exception to errors.
<br>>>
<br>> Here's my feeling on this.
<br>>
<br>> If you have some expected object and you do `.value` on it (or any=
of its
<br>> equivalents), what you are saying very clearly is this: I fully an=
d
<br>> completely expect that this object will not be in the error state.=
That's
<br>> the conceptual precondition of your code.
<br>No. value is a wide interface. We could add a narrow dereference=20
<br>function if we think is useful.
<br>>
<br>> If that condition is violated, then the problem with your code is =
that the
<br>> condition was violated. That is, the problem with your code is not=
that a
<br>> function emitted an error of some type. It's that a function e=
mitted an
<br>> error and *you didn't check it*. This is the same error no mat=
ter what the
<br>> error code type is, so it should throw the same exception from eve=
ry
<br>> `expected` object.
<br>You reached to lost me. have you read the expected proposal?
<br>> That being said, I could see having a `throw_if_error` function, w=
hich will
<br>> throw an exception based on the error code if the expected object =
is in the
<br>> error state.
<br>Oh, I see that you have not, or you have forgotten the proposed interfa=
ce?<br></blockquote></div></div><div><br>The last expected proposal was ove=
r a year ago. I don't know why you would expect everyone to be familiar=
with every aspect of its design.<br><br>That being said, why not have a `t=
hrow_if_error` function that actually throws `E` (or throws the exception c=
ontained in an `exception_ptr`)?<br>=C2=A0</div><span><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex">>
<br>> Also, we don't want to overburden `expected` with customizatio=
n machinery.
<br>> Not unless there's a really good reason. I don't want to h=
ave to hunt down
<br>> some traits class to see what I should have to catch. Throwing the=
error
<br>> code type itself, whatever that type is, should be sufficient for =
a
<br>> function like `throw_if_error`.
<br>Please, refer to the proposal. Do you mean that expected<T,E>::va=
lue()=20
<br>should throw an exception E?
<br>What about expected<T,exception_ptr>, should throw an exception_p=
tr?
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> After all, I&=
#39;ve always felt that the point of `expected` was to *not* use
<br>> exceptions, to have an alternative to them.
<br>Some could make this use, but expected works very well with exceptions.=
=20
<br>There is no either you use exceptions or you use expected decision to m=
ake.
<br></blockquote></span><div><br>But there is such a decision to make. I re=
call a discussion about this.<br><br>If `expected` holds an `exception_ptr`=
, then the only useful thing a user can do with that is throw it. They can&=
#39;t test it. They can't print it. They can only throw it and catch th=
e result. That makes for a useless error code value, so I seriously doubt a=
nyone will use it as such.<br><br>In short, you're not going to see a l=
ot of `expected<T, exception_ptr>`. It just doesn't make sense. Y=
ou may as well have just thrown the exception directly. After all, the <i>o=
nly way</i> to create an `exception_ptr` is to throw an exception, so you&#=
39;ve already paid the price one time.</div></blockquote><div><br></div><di=
v>std::make_exception_ptr().<br></div></div></div></div></blockquote><div><=
br>I don't know why I thought that was from a proposal someone made. Ma=
ybe it was for a perfect forwarding version...</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9027_1219798437.1447284180348--
------=_Part_9026_205876576.1447284180348--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 00:30:42 +0100
Raw View
Le 12/11/2015 00:14, Tony V E a =C3=A9crit :
> On Wed, Nov 11, 2015 at 5:37 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Le 11/11/2015 23:25, Tony V E a =C3=A9crit :
>>
>>> On Wed, Nov 11, 2015 at 4:27 PM, Vicente J. Botet Escriba <
>>> vicente.botet@wanadoo.fr> wrote:
>>>
>>> Le 11/11/2015 22:12, Tony V E a =C3=A9crit :
>>>> On Wed, Nov 11, 2015 at 3:01 PM, Vicente J. Botet Escriba <
>>>>> vicente.botet@wanadoo.fr> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Erro=
r>>
>>>>>>
>>>>>>
>>>>>> Not sure what I think of this, but I'll suggest it anyhow: make the
>>>>>>
>>>>> traits
>>>>> into wrapper classes:
>>>>>
>>>>> 0. expected<T, E> // default: if E is exception or exception_ptr
>>>>> throw
>>>>> it, otherwise throw bad_access<E>
>>>>>
>>>>> 1. expected<T, as_error<Ex>> // even if Ex is an exception, treat=
it
>>>>> like an error - ie always throw bad_access<Ex>
>>>>>
>>>>> 2. expected<T, as_exception<Err>> // even if Err is NOT an
>>>>> exception,
>>>>> always throw Err
>>>>>
>>>>>
>>>>> So really expected<T,E> looks for an expected-friendly interface on E
>>>>> (similar to your traits interface), and if it finds it, it uses it.
>>>>> Otherwise it uses its "magic" default behaviour. as_error<> and
>>>>> as_exception<> would be two common ways of building the
>>>>> expected-friendly
>>>>> interface.
>>>>>
>>>>> Not sure if I like that any better. But it sort of lessens the weigh=
t
>>>>> for
>>>>> the average user.
>>>>>
>>>>> Are you proposing that expected is aware of as_error and as_exception=
?
>>>>>
>>>> Not exactly. It only appears that way. In reality, it would probably=
be
>>> that as_error<> and as_exception<> either both derive from
>>> expected_error_handler_interface or at least both implement the right
>>> member functions which are detected at compile time.
>>> So you could pass in your own E that happens to implement the correct
>>> interface, and we just happen to supply 2 common/useful examples.
>>>
>>> It's very similar to traits. Just sort or moves where/how the
>>> customization happens.
>>>
>>> It would be difficult to describe what is the error and the exception
>> associated to expected<T,E>, isn't it?
>
> Probably. If could be something like "if E has a nested type
> E::expected_error... otherwise if E is std::error_code... otherwise the
> error is E"
> Or something like that.
>
> I'm still not saying it is a good idea, just an idea that I think is wort=
h
> considering.
>
>
Thanks Tony,
I have considered it already, and I found that it quite close to a=20
Hammer ;-)
It would be very useful to have a paper of what the standard contains=20
that shouldn't be redone.
* don't use traits?
By the way I see that the executor_traits proposal had quite good=20
acceptation.
And even better, what should be done.
How we customize behavior, when to customize, without having one or=20
another telling you that this is not the way to go.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 13:23:28 +0100
Raw View
Le 11/11/2015 22:56, 'Matt Calabrese' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Nov 11, 2015 at 1:36 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>> Would you be against/for having two classes
>>
>> expected<T>
>>
>> throws the exception stored in the exception_ptr
>>
>> expected_or_error<T,E> // or whatever better name we find
>>
>> throws E
>>
> I'd rather just have a single excepted<T, E> and either always specify
> throw or always specify UB.
This is not what I asked. we have already both throw and UB depending on=20
the operation.
> If I happen to be there for a poll for an
> expected proposal where expected<T, E> always specifies throw, I would no=
t
> vote against it just because of that alone. The facility is very useful
> regardless and the difference doesn't impact my uses enough.
But this is not the case. No one is proposing to throw always.
> As long as the
> template is consistent, I'm happy enough. I would, however, vote against
> the proposal if it threw *only* when E is std::exception_ptr or is
> otherwise determined to be an "exception" type.
No one is proposing that, isn't it?
>
> So, my thoughts are just 1 template that is consistent, regardless of
> whether than means always specify throwing or always specifying UB.
This is not what I asked. This is another approach.
I see that I must add the value() operation throws either the exception=20
stored in exception pointer for the first template expected<T>, and=20
value() throw E or bad_expected_access<E>.
Nevin, is this the kind of design you were talking of, having different=20
names for different behaviors?
Vicente
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 12 Nov 2015 09:56:16 -0500
Raw View
On 2015-11-11 18:00, Nicol Bolas wrote:
> If I'm writing a function that can fail, I can choose to signal that=20
> failure in one of two ways: exception or expected. If I use `expected`,=
=20
> then I have to choose what to return in the case of failure. Returning a=
=20
> big object bloats the return value, so I have an incentive to minimize th=
e=20
> error data.
Is that still true if you return a *pointer*=C2=B9 to a big object? That wa=
y
the size of the expected itself is minimal (a pointer, plus the overhead
of expected), but you still have the option of returning detailed error
information (which you pay for only in case of errors).
(=C2=B9 Obviously, some form of smart pointer is implied.)
> And because the direct caller will be the one who handles it=20
> (in all likelihood), he doesn't need to know much more than that the=20
> operation failed. He doesn't need a string or a complex data structure=20
> storing what happened. He knows exactly what he asked for, and he knows=
=20
> exactly where it failed. All he needs to know is why.
OTOH this is probably true *most* of the time. Not always. Say for
example that the operation returning the expected was compiling a GLSL
shader; the input is shader code, the output is a shader handle. But if
something goes sideways, you probably want the compile log, which is in
no way obvious just from knowing the input you fed the compile function.
(I can come up with other, similar examples; generally where the
function being called is "doing a lot".)
> Notice how the FileSystem TS's exception type holds rich data, while the=
=20
> error code is just a number.
FWIW, I'll note that one reason this probably makes sense is that all
the functions directly know about the cause of the error is an error
code anyway (from the underlying OS function). As you indicate, the rest
would, I presume, be built up from the inputs to the function that
failed. (So, indeed, in this case the immediate caller already has the
same information and just needs back the OS error code, or possibly a
"normalized" version thereof i.e. mapped to a cross-platform set of
error codes.)
> Emitting an exception is a heavy-weight operation, so making it slightly=
=20
> heavier by returning rich data is fine. Returning an expected is a=20
> light-weight operation, so making it heavier is a bad thing.
....in case of a value return, definitely. I'd be less worried about
error returns being heavy, as long as they don't hurt value returns.
--=20
Matthew
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 07:14:12 -0800 (PST)
Raw View
------=_Part_473_2069126764.1447341253157
Content-Type: multipart/alternative;
boundary="----=_Part_474_100335399.1447341253162"
------=_Part_474_100335399.1447341253162
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 11, 2015 at 6:19:03 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 12/11/2015 00:00, Nicol Bolas a =C3=A9crit :=20
> > On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Botet=
=20
> > Escriba wrote:=20
> >> Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :=20
> >>> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicente J. Botet=
=20
> >>> Escriba wrote:=20
> >>>> Hi,=20
> >>>>=20
> >>>> I would like to re-raise the expected discussion. Beside the=20
> >> conflicting=20
> >>>> part "managing errors in a different way", that should be covered by=
=20
> a=20
> >>>> specific paper, I would like to open the discussion in order to have=
=20
> a=20
> >>>> better proposal for expected.=20
> >>>>=20
> >>>> There were some concerns about the exception throw when there is no=
=20
> >> value.=20
> >>>> I'm wondering if we can do as for basic_string, we can have an=20
> >> error_traits=20
> >>>> that define which exception is thrown and that can also do conversio=
n=20
> >> from=20
> >>>> exception to errors.=20
> >>>>=20
> >>> Here's my feeling on this.=20
> >>>=20
> >>> If you have some expected object and you do `.value` on it (or any of=
=20
> >> its=20
> >>> equivalents), what you are saying very clearly is this: I fully and=
=20
> >>> completely expect that this object will not be in the error state.=20
> >> That's=20
> >>> the conceptual precondition of your code.=20
> >> No. value is a wide interface. We could add a narrow dereference=20
> >> function if we think is useful.=20
> >>> If that condition is violated, then the problem with your code is tha=
t=20
> >> the=20
> >>> condition was violated. That is, the problem with your code is not=20
> that=20
> >> a=20
> >>> function emitted an error of some type. It's that a function emitted=
=20
> an=20
> >>> error and *you didn't check it*. This is the same error no matter wha=
t=20
> >> the=20
> >>> error code type is, so it should throw the same exception from every=
=20
> >>> `expected` object.=20
> >> You reached to lost me. have you read the expected proposal?=20
> >>> That being said, I could see having a `throw_if_error` function, whic=
h=20
> >> will=20
> >>> throw an exception based on the error code if the expected object is=
=20
> in=20
> >> the=20
> >>> error state.=20
> >> Oh, I see that you have not, or you have forgotten the proposed=20
> interface?=20
> >>=20
> > The last expected proposal was over a year ago. I don't know why you=20
> would=20
> > expect everyone to be familiar with every aspect of its design.=20
> >=20
> > That being said, why not have a `throw_if_error` function that actually=
=20
> > throws `E` (or throws the exception contained in an `exception_ptr`)?=
=20
> We have already it value().
>
`value` access the value; throwing an exception is part of the interface,=
=20
but it's not the purpose of the function. Furthermore, because=20
`throw_if_error` is a different function, it can reasonably be given=20
different semantics. So `value` would always throw some form of=20
`bad_expected` or whatever. While `throw_if_error` would throw E, or=20
rethrow an `exception_ptr`.
> =20
> >=20
> >>> Also, we don't want to overburden `expected` with customization=20
> >> machinery.=20
> >>> Not unless there's a really good reason. I don't want to have to hunt=
=20
> >> down=20
> >>> some traits class to see what I should have to catch. Throwing the=20
> error=20
> >>> code type itself, whatever that type is, should be sufficient for a=
=20
> >>> function like `throw_if_error`.=20
> >> Please, refer to the proposal. Do you mean that expected<T,E>::value()=
=20
> >> should throw an exception E?=20
> >> What about expected<T,exception_ptr>, should throw an exception_ptr?=
=20
> >>=20
> >> After all, I've always felt that the point of `expected` was to *not*=
=20
> use=20
> >>> exceptions, to have an alternative to them.=20
> >> Some could make this use, but expected works very well with exceptions=
..=20
> >> There is no either you use exceptions or you use expected decision to=
=20
> >> make.=20
> >>=20
> > But there is such a decision to make. I recall a discussion about this.=
=20
> >=20
> > If `expected` holds an `exception_ptr`, then the only useful thing a=20
> user=20
> > can do with that is throw it. They can't test it. They can't print it.=
=20
> They=20
> > can only throw it and catch the result. That makes for a useless error=
=20
> code=20
> > value, so I seriously doubt anyone will use it as such.=20
> I will use it as the underlying type for future e.g.=20
>
Do you mean like `future<expected<T, exception_ptr>>`? Why would you *ever*=
=20
want to do that? Promise/future already has a perfectly reasonable way to=
=20
pass exceptions through it. If this were 2009 and promise/future were still=
=20
on the drawing board, maybe. But now that they've had exception transfer=20
machinery for years? There's just no point to this.
>=20
> > In short, you're not going to see a lot of `expected<T, exception_ptr>`=
..=20
> It=20
> > just doesn't make sense. You may as well have just thrown the exception=
=20
> > directly. After all, the *only way* to create an `exception_ptr` is to=
=20
> > throw an exception, so you've already paid the price one time. There is=
=20
> > absolutely no reason to catch an exception, package it into an=20
> `expected<T,=20
> > exception_ptr>`, and then give it to someone who's *only useful option*=
=20
> is=20
> > to throw it again.=20
> There are other worlds where we want to use it.=20
> >=20
> > Throwing exceptions isn't cheap. That's a cost that needs to be paid at=
=20
> > most once.=20
> Not if the exception was already thrown independently of whether you=20
> will store it in expected or rethrow it.=20
> >=20
> > If I'm writing a function that can fail, I can choose to signal that=20
> > failure in one of two ways: exception or expected. If I use `expected`,=
=20
> > then I have to choose what to return in the case of failure. Returning =
a=20
> > big object bloats the return value, so I have an incentive to minimize=
=20
> the=20
> > error data. And because the direct caller will be the one who handles i=
t=20
> > (in all likelihood), he doesn't need to know much more than that the=20
> > operation failed. He doesn't need a string or a complex data structure=
=20
> > storing what happened. He knows exactly what he asked for, and he knows=
=20
> > exactly where it failed. All he needs to know is why.=20
> Function that return expected can call other functions that throw=20
> exceptions, isn't it?
>
OK, there are generally two kinds of users who will use `expected`. There=
=20
are those who prefer local exception handling, either in a particular few=
=20
cases or as a general rule. And there are those who simply *cannot* use=20
exceptions.
If you call a function that throws, you are obviously not in the latter=20
category. Which means that your code is perfectly capable of handling=20
exceptions. So just... *do that*. If your function is not going to actually=
=20
handle the exception, just let it propagate through up to whomever really=
=20
is going to handle it.
The only time I could see `expected<T, exception_ptr>` possibly being=20
useful would be for passage of an exception through a C library. Of course,=
=20
how you pass that C++ type through C at all is an open question. And even=
=20
this is a rare case. It should certainly be allowed, but it shouldn't be=20
common enough to have special case handling for `expected` when it holds an=
=20
`exception_ptr`.
=20
> >=20
> > If I throw an exception, I *must* assume that the person catching it ma=
y=20
> > have very little information about the particulars of the call that=20
> caused=20
> > it. Therefore, my exception must store a lot of data, so that the=20
> receiver=20
> > can know what to do with it.=20
> >=20
> > Notice how the FileSystem TS's exception type holds rich data, while th=
e=20
> > error code is just a number.=20
> >=20
> > Emitting an exception is a heavy-weight operation, so making it slightl=
y=20
> > heavier by returning rich data is fine. Returning an expected is a=20
> > light-weight operation, so making it heavier is a bad thing. We should=
=20
> not=20
> > confuse the two and try to treat expected as some kind of precursor to=
=20
> an=20
> > exception.=20
> I don't believe I'm confusing the two?=20
>
And yet, that's what your entire post here has been. You frequently talk=20
about converting exceptions into expected and vice-versa. These are two=20
separate and distinct error mechanisms.
This is also something I recall we discussed. You effectively wanted to=20
have API interfaces return `expected` objects by default. But you wanted to=
=20
allow users to decide whether to use exceptions by having them call=20
`value`, so these objects would be `expected<T, exception_ptr>`. And with=
=20
the rethrow behavior you wanted in `value`, you would get the exception you=
=20
would normally expect from the API.
That's confusing the two error mechanisms. By returning `expected<T,=20
exception_ptr>`, you effectively limit the usefulness of that API. Users=20
who operate in fields where exceptions are not allowed *cannot* use your=20
API, because if exceptions aren't allowed, odds are good that the memory=20
allocations needed for `make_exception_ptr` aren't allowed either. Even=20
users who simply choose not to use exceptions lose with such an interface.=
=20
Because all they get for an error code is an opaque pointer, not an error=
=20
code that they could use to see *why* an operation failed.
Or at least, not without throwing it. A thing they were specifically trying=
=20
to avoid. You may as well have given them `expected<T, monostate>`. At=20
least then, they wouldn't get an unnecessary memory allocation.
APIs that use `expected` should not look like APIs that would throw=20
exceptions. And a user who calls the `expected` form does not generally=20
want to transform it into an exception.
I'm fine with `value` throwing; it fits with other similar types (optional,=
=20
etc). What I'm against is the idea that we should dynamically switch=20
between expected and exceptions, that they should be equated and easily=20
inter-operable.
=20
> > =20
> >=20
> >>> It seems kinda silly to add a=20
> >>> customization point solely for exception behavior, when that's exactl=
y=20
> >> what=20
> >>> you're trying to avoid.=20
> >>>=20
> >> It seems that you don't understand the purpose of expected.=20
> >=20
> > I understand what *I want* from expected.=20
> If you know what you want, the best we can do is to write a proposal ;-)=
=20
> > You seem to think of it as some=20
> > functional programming gizmo or some way of passing exceptions around.=
=20
> For=20
> > me, it's an *alternative* mechanism of error reporting that is biased=
=20
> > towards local error handling rather than non-local handling.=20
> You are right, expected is a error reporting mechanism that needs local=
=20
> error handling. However the await proposal gives him a transparent=20
> non-local erro reporting.
If you have to annotate every propagation of an error with `await`, it's=20
not "transparent". If you have to modify your return value, it's not=20
"transparent". If you can't pass different kinds of error codes without=20
even more modifications to your return value (`expected<T, variant<E1, E2,=
=20
....>>`), it's not "transparent". And if functions that use this syntax=20
can't also use futures or other forms of `await`, it's not "transparent".
Hijacking `await` machinery has consequences. And those consequences are=20
far from "transparent" to the user. I would personally much rather you just=
=20
use the right error mechanism. If you want local handling, call the API=20
that returns `expected`. If you want non-local handling, call the API that=
=20
throws.
=20
> Since the original proposal there was some=20
> kind of do-notation that simplified the error reporting. Now we ave=20
> await :)=20
> > =20
> >=20
> >> If proposed=20
> >> expected is able to throw an exception when there is no value. That's=
=20
> it.=20
> >> The question is which exception.=20
> >>=20
> > And I said "it seems kinda silly to *add a customization point solely=
=20
> for=20
> > exception behavior*, when that's exactly what you're trying to avoid."=
=20
> So=20
> > on the matter of customizable exceptions, I say no.=20
> >=20
> It is the fist time someone has said that. Now you and Mat say that we=20
> don't need to throw any exception.
I never said that `value` shouldn't throw. Indeed, I said quite the=20
opposite: "it should throw the same exception from every `expected` object.=
"
But please keep in mind Study Group 14. These are people who cannot use=20
exceptions. People who cannot have objects randomly allocating memory. But=
=20
they are also people who need a good alternative error handling mechanism,=
=20
one that can be added to standard library interfaces so that they can use=
=20
them in lieu of the exception versions.
`expected` is exactly what they're looking for. If `value` throws, that's=
=20
fine; they can just avoid calling it. But they need to be able to have an=
=20
alternative error mechanism that can be standardized. You should probably=
=20
get with those guys, because they could probably help `expected` get pushed=
=20
forward. It's exactly the sort of thing they want.
Oh, and one more thing. `expected` is, functionally speaking, a kind of=20
never-empty variant with a specialized interface. So I'm curious as to=20
exactly how you solve the various issues that surrounded the more=20
generalized `variant` class. It's not clear from your current proposal how=
=20
you can provide the exception guarantees that it claims.
For example, on copy-assignment from another `expected`, you say that if=20
the copy constructor for the type in the source expected fails, "no=20
effect". How do you implement that if `T` or `E` is not nothrow=20
copy/moveable? Do you double-buffer?
I suggest you take a look at the current P0088 variant proposal and=20
investigate the issues that prompted it to get an `invalid` state. Because=
=20
`expected` only has two types, and one of them is an error type, you could=
=20
probably impose more restrictive requirements on E that make it possible to=
=20
implement your guarantees. For example, you could require that E is nothrow=
=20
moveable, which makes it possible to implement your guarantees without=20
double-buffering.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_474_100335399.1447341253162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 11, 2015 at 6:19:03 PM UTC-5, Vicente J. Botet Escri=
ba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 12/11/2015 00:00, =
Nicol Bolas a =C3=A9crit :
<br>> On Wednesday, November 11, 2015 at 4:27:58 PM UTC-5, Vicente J. Bo=
tet
<br>> Escriba wrote:
<br>>> Le 11/11/2015 21:29, Nicol Bolas a =C3=A9crit :
<br>>>> On Wednesday, November 11, 2015 at 3:01:19 PM UTC-5, Vicen=
te J. Botet
<br>>>> Escriba wrote:
<br>>>>> Hi,
<br>>>>>
<br>>>>> I would like to re-raise the expected discussion. Besi=
de the
<br>>> conflicting
<br>>>>> part "managing errors in a different way", t=
hat should be covered by a
<br>>>>> specific paper, I would like to open the discussion in=
order to have a
<br>>>>> better proposal for expected.
<br>>>>>
<br>>>>> There were some concerns about the exception throw whe=
n there is no
<br>>> value.
<br>>>>> I'm wondering if we can do as for basic_string, we=
can have an
<br>>> error_traits
<br>>>>> that define which exception is thrown and that can als=
o do conversion
<br>>> from
<br>>>>> exception to errors.
<br>>>>>
<br>>>> Here's my feeling on this.
<br>>>>
<br>>>> If you have some expected object and you do `.value` on it=
(or any of
<br>>> its
<br>>>> equivalents), what you are saying very clearly is this: I =
fully and
<br>>>> completely expect that this object will not be in the erro=
r state.
<br>>> That's
<br>>>> the conceptual precondition of your code.
<br>>> No. value is a wide interface. We could add a narrow dereferen=
ce
<br>>> function if we think is useful.
<br>>>> If that condition is violated, then the problem with your =
code is that
<br>>> the
<br>>>> condition was violated. That is, the problem with your cod=
e is not that
<br>>> a
<br>>>> function emitted an error of some type. It's that a fu=
nction emitted an
<br>>>> error and *you didn't check it*. This is the same erro=
r no matter what
<br>>> the
<br>>>> error code type is, so it should throw the same exception =
from every
<br>>>> `expected` object.
<br>>> You reached to lost me. have you read the expected proposal?
<br>>>> That being said, I could see having a `throw_if_error` fun=
ction, which
<br>>> will
<br>>>> throw an exception based on the error code if the expected=
object is in
<br>>> the
<br>>>> error state.
<br>>> Oh, I see that you have not, or you have forgotten the propose=
d interface?
<br>>>
<br>> The last expected proposal was over a year ago. I don't know w=
hy you would
<br>> expect everyone to be familiar with every aspect of its design.
<br>>
<br>> That being said, why not have a `throw_if_error` function that act=
ually
<br>> throws `E` (or throws the exception contained in an `exception_ptr=
`)?
<br>We have already it value().<br></blockquote><div><br>`value` access the=
value; throwing an exception is part of the interface, but it's not th=
e purpose of the function. Furthermore, because `throw_if_error` is a diffe=
rent function, it can reasonably be given different semantics. So `value` w=
ould always throw some form of `bad_expected` or whatever. While `throw_if_=
error` would throw E, or rethrow an `exception_ptr`.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">> =C2=A0=20
<br>>
<br>>>> Also, we don't want to overburden `expected` with cust=
omization
<br>>> machinery.
<br>>>> Not unless there's a really good reason. I don't w=
ant to have to hunt
<br>>> down
<br>>>> some traits class to see what I should have to catch. Thro=
wing the error
<br>>>> code type itself, whatever that type is, should be suffici=
ent for a
<br>>>> function like `throw_if_error`.
<br>>> Please, refer to the proposal. Do you mean that expected<T,=
E>::value()
<br>>> should throw an exception E?
<br>>> What about expected<T,exception_ptr>, should throw an ex=
ception_ptr?
<br>>>
<br>>> After all, I've always felt that the point of `expected` w=
as to *not* use
<br>>>> exceptions, to have an alternative to them.
<br>>> Some could make this use, but expected works very well with ex=
ceptions.
<br>>> There is no either you use exceptions or you use expected deci=
sion to
<br>>> make.
<br>>>
<br>> But there is such a decision to make. I recall a discussion about =
this.
<br>>
<br>> If `expected` holds an `exception_ptr`, then the only useful thing=
a user
<br>> can do with that is throw it. They can't test it. They can'=
;t print it. They
<br>> can only throw it and catch the result. That makes for a useless e=
rror code
<br>> value, so I seriously doubt anyone will use it as such.
<br>I will use it as the underlying type for future e.g.
<br></blockquote><div><br>Do you mean like `future<expected<T, except=
ion_ptr>>`? Why would you <i>ever</i> want to do that? Promise/future=
already has a perfectly reasonable way to pass exceptions through it. If t=
his were 2009 and promise/future were still on the drawing board, maybe. Bu=
t now that they've had exception transfer machinery for years? There=
9;s just no point to this.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">>
<br>> In short, you're not going to see a lot of `expected<T, exc=
eption_ptr>`. It
<br>> just doesn't make sense. You may as well have just thrown the =
exception
<br>> directly. After all, the *only way* to create an `exception_ptr` i=
s to
<br>> throw an exception, so you've already paid the price one time.=
There is
<br>> absolutely no reason to catch an exception, package it into an `ex=
pected<T,
<br>> exception_ptr>`, and then give it to someone who's *only us=
eful option* is
<br>> to throw it again.
<br>There are other worlds where we want to use it.
<br>>
<br>> Throwing exceptions isn't cheap. That's a cost that needs =
to be paid at
<br>> most once.
<br>Not if the exception was already thrown independently of whether you=20
<br>will store it in expected or rethrow it.
<br>>
<br>> If I'm writing a function that can fail, I can choose to signa=
l that
<br>> failure in one of two ways: exception or expected. If I use `expec=
ted`,
<br>> then I have to choose what to return in the case of failure. Retur=
ning a
<br>> big object bloats the return value, so I have an incentive to mini=
mize the
<br>> error data. And because the direct caller will be the one who hand=
les it
<br>> (in all likelihood), he doesn't need to know much more than th=
at the
<br>> operation failed. He doesn't need a string or a complex data s=
tructure
<br>> storing what happened. He knows exactly what he asked for, and he =
knows
<br>> exactly where it failed. All he needs to know is why.
<br>Function that return expected can call other functions that throw=20
<br>exceptions, isn't it?<br></blockquote><div><br>OK, there are genera=
lly two kinds of users who will use `expected`. There are those who prefer =
local exception handling, either in a particular few cases or as a general =
rule. And there are those who simply <i>cannot</i> use exceptions.<br><br>I=
f you call a function that throws, you are obviously not in the latter cate=
gory. Which means that your code is perfectly capable of handling exception=
s. So just... <i>do that</i>. If your function is not going to actually han=
dle the exception, just let it propagate through up to whomever really is g=
oing to handle it.<br><br>The only time I could see `expected<T, excepti=
on_ptr>` possibly being useful would be for passage of an exception thro=
ugh a C library. Of course, how you pass that C++ type through C at all is =
an open question. And even this is a rare case. It should certainly be allo=
wed, but it shouldn't be common enough to have special case handling fo=
r `expected` when it holds an `exception_ptr`.<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">>
<br>> If I throw an exception, I *must* assume that the person catching =
it may
<br>> have very little information about the particulars of the call tha=
t caused
<br>> it. Therefore, my exception must store a lot of data, so that the =
receiver
<br>> can know what to do with it.
<br>>
<br>> Notice how the FileSystem TS's exception type holds rich data,=
while the
<br>> error code is just a number.
<br>>
<br>> Emitting an exception is a heavy-weight operation, so making it sl=
ightly
<br>> heavier by returning rich data is fine. Returning an expected is a
<br>> light-weight operation, so making it heavier is a bad thing. We sh=
ould not
<br>> confuse the two and try to treat expected as some kind of precurso=
r to an
<br>> exception.
<br>I don't believe I'm confusing the two?
<br></blockquote><div><br>And yet, that's what your entire post here ha=
s been. You frequently talk about converting exceptions into expected and v=
ice-versa. These are two separate and distinct error mechanisms.<br><br>Thi=
s is also something I recall we discussed. You effectively wanted to have A=
PI interfaces return `expected` objects by default. But you wanted to allow=
users to decide whether to use exceptions by having them call `value`, so =
these objects would be `expected<T, exception_ptr>`. And with the ret=
hrow behavior you wanted in `value`, you would get the exception you would =
normally expect from the API.<br><br>That's confusing the two error mec=
hanisms. By returning `expected<T, exception_ptr>`, you effectively l=
imit the usefulness of that API. Users who operate in fields where exceptio=
ns are not allowed <i>cannot</i> use your API, because if exceptions aren&#=
39;t allowed, odds are good that the memory allocations needed for `make_ex=
ception_ptr` aren't allowed either. Even users who simply choose not to=
use exceptions lose with such an interface. Because all they get for an er=
ror code is an opaque pointer, not an error code that they could use to see=
<i>why</i> an operation failed.<br><br>Or at least, not without throwing i=
t. A thing they were specifically trying to avoid. You may as well have giv=
en them `expected<T, monostate>`. At least then, they wouldn't ge=
t an unnecessary memory allocation.<br><br>APIs that use `expected` should =
not look like APIs that would throw exceptions. And a user who calls the `e=
xpected` form does not generally want to transform it into an exception.<br=
><br>I'm fine with `value` throwing; it fits with other similar types (=
optional, etc). What I'm against is the idea that we should dynamically=
switch between expected and exceptions, that they should be equated and ea=
sily inter-operable.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">> =C2=A0=20
<br>>
<br>>>> It seems kinda silly to add a
<br>>>> customization point solely for exception behavior, when th=
at's exactly
<br>>> what
<br>>>> you're trying to avoid.
<br>>>>
<br>>> It seems that you don't understand the purpose of expected=
..
<br>>
<br>> I understand what *I want* from expected.
<br>If you know what you want, the best we can do is to write a proposal ;-=
)
<br>> You seem to think of it as some
<br>> functional programming gizmo or some way of passing exceptions aro=
und. For
<br>> me, it's an *alternative* mechanism of error reporting that is=
biased
<br>> towards local error handling rather than non-local handling.
<br>You are right, expected is a error reporting mechanism that needs local=
=20
<br>error handling. However the await proposal gives him a transparent=20
<br>non-local erro reporting.</blockquote><div><br>If you have to annotate =
every propagation of an error with `await`, it's not "transparent&=
quot;. If you have to modify your return value, it's not "transpar=
ent". If you can't pass different kinds of error codes without eve=
n more modifications to your return value (`expected<T, variant<E1, E=
2, ...>>`), it's not "transparent". And if functions th=
at use this syntax can't also use futures or other forms of `await`, it=
's not "transparent".<br><br>Hijacking `await` machinery has =
consequences. And those consequences are far from "transparent" t=
o the user. I would personally much rather you just use the right error mec=
hanism. If you want local handling, call the API that returns `expected`. I=
f you want non-local handling, call the API that throws.<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">Since the original proposal there=
was some=20
<br>kind of do-notation that simplified the error reporting. Now we ave=20
<br>await :)
<br>> =C2=A0=20
<br>>
<br>>> If proposed
<br>>> expected is able to throw an exception when there is no value.=
That's it.
<br>>> The question is which exception.
<br>>>
<br>> And I said "it seems kinda silly to *add a customization poin=
t solely for
<br>> exception behavior*, when that's exactly what you're tryin=
g to avoid." So
<br>> on the matter of customizable exceptions, I say no.
<br>>
<br>It is the fist time someone has said that. Now you and Mat say that we=
=20
<br>don't need to throw any exception.</blockquote><div><br>I never sai=
d that `value` shouldn't throw. Indeed, I said quite the opposite: &quo=
t;it should throw the same exception from every `expected` object."<br=
><br>But please keep in mind Study Group 14. These are people who cannot us=
e exceptions. People who cannot have objects randomly allocating memory. Bu=
t they are also people who need a good alternative error handling mechanism=
, one that can be added to standard library interfaces so that they can use=
them in lieu of the exception versions.<br><br>`expected` is exactly what =
they're looking for. If `value` throws, that's fine; they can just =
avoid calling it. But they need to be able to have an alternative error mec=
hanism that can be standardized. You should probably get with those guys, b=
ecause they could probably help `expected` get pushed forward. It's exa=
ctly the sort of thing they want.<br><br>Oh, and one more thing. `expected`=
is, functionally speaking, a kind of never-empty variant with a specialize=
d interface. So I'm curious as to exactly how you solve the various iss=
ues that surrounded the more generalized `variant` class. It's not clea=
r from your current proposal how you can provide the exception guarantees t=
hat it claims.<br><br>For example, on copy-assignment from another `expecte=
d`, you say that if the copy constructor for the type in the source expecte=
d fails, "no effect". How do you implement that if `T` or `E` is =
not nothrow copy/moveable? Do you double-buffer?<br><br>I suggest you take =
a look at the current P0088 variant proposal and investigate the issues tha=
t prompted it to get an `invalid` state. Because `expected` only has two ty=
pes, and one of them is an error type, you could probably impose more restr=
ictive requirements on E that make it possible to implement your guarantees=
.. For example, you could require that E is nothrow moveable, which makes it=
possible to implement your guarantees without double-buffering.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_474_100335399.1447341253162--
------=_Part_473_2069126764.1447341253157--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 12 Nov 2015 10:15:21 -0500
Raw View
On 2015-11-11 15:52, Tony V E wrote:
> I'm not disagreeing, but the other example is vector<bool>. (Allocators,
> vector<bool>, iostreams - things to be unfavourably compared to).
>
> I was unsure about expected<T, E> working differently when E is an
> exception, vs when E is an int or any other error.
> Particularly since in C++, almost anything can be thrown as an exception.
> But we could define "is an exception" to be "derived from std::exception".
> Or is exception_ptr. Or...
What if expected had a method assert() that either does nothing (if
expected has a value) or throws the error (if expected has an error)?
*Maybe* this method would be conditionally enabled depending on if the
error type is exception-like...
....Would that be a satisfactory compromise?
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 07:25:07 -0800 (PST)
Raw View
------=_Part_54_1250118934.1447341907997
Content-Type: multipart/alternative;
boundary="----=_Part_55_2006333581.1447341907997"
------=_Part_55_2006333581.1447341907997
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 9:56:32 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-11 18:00, Nicol Bolas wrote:=20
> > If I'm writing a function that can fail, I can choose to signal that=20
> > failure in one of two ways: exception or expected. If I use `expected`,=
=20
> > then I have to choose what to return in the case of failure. Returning =
a=20
> > big object bloats the return value, so I have an incentive to minimize=
=20
> the=20
> > error data.=20
>
> Is that still true if you return a *pointer*=C2=B9 to a big object? That =
way=20
> the size of the expected itself is minimal (a pointer, plus the overhead=
=20
> of expected), but you still have the option of returning detailed error=
=20
> information (which you pay for only in case of errors).=20
>
> (=C2=B9 Obviously, some form of smart pointer is implied.)=20
>
True, a (smart) pointer wouldn't bloat the return value per-se, so you=20
wouldn't pay a price all the time. But that means that errors become much=
=20
more heavy-weight, since they require a memory allocation.
> And because the direct caller will be the one who handles it=20
> > (in all likelihood), he doesn't need to know much more than that the=20
> > operation failed. He doesn't need a string or a complex data structure=
=20
> > storing what happened. He knows exactly what he asked for, and he knows=
=20
> > exactly where it failed. All he needs to know is why.=20
>
> OTOH this is probably true *most* of the time. Not always. Say for=20
> example that the operation returning the expected was compiling a GLSL=20
> shader; the input is shader code, the output is a shader handle. But if=
=20
> something goes sideways, you probably want the compile log, which is in=
=20
> no way obvious just from knowing the input you fed the compile function.=
=20
> (I can come up with other, similar examples; generally where the=20
> function being called is "doing a lot".)
>
True. But generally speaking, I would implement such a GLSL error object by=
=20
having the error object be able to fetch the log if the user wants it to do=
=20
so. This means the error object would store a GLSL shader object handle and=
=20
will destroy it when the error object is destroyed.
This would again be to avoid requiring a memory allocation in case of an=20
error. If the user wants that memory allocation, they get to have it. But=
=20
it shouldn't be forced on them just because shader compilation/linking=20
failed.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_55_2006333581.1447341907997
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, November 12, 2015 at 9:56:32 AM UTC-5, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-11 =
18:00, Nicol Bolas wrote:
<br>> If I'm writing a function that can fail, I can choose to signa=
l that=20
<br>> failure in one of two ways: exception or expected. If I use `expec=
ted`,=20
<br>> then I have to choose what to return in the case of failure. Retur=
ning a=20
<br>> big object bloats the return value, so I have an incentive to mini=
mize the=20
<br>> error data.
<br>
<br>Is that still true if you return a *pointer*=C2=B9 to a big object? Tha=
t way
<br>the size of the expected itself is minimal (a pointer, plus the overhea=
d
<br>of expected), but you still have the option of returning detailed error
<br>information (which you pay for only in case of errors).
<br>
<br>(=C2=B9 Obviously, some form of smart pointer is implied.)
<br></blockquote><div><br>True, a (smart) pointer wouldn't bloat the re=
turn value per-se, so you wouldn't pay a price all the time. But that m=
eans that errors become much more heavy-weight, since they require a memory=
allocation.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> And because the direct caller will be the one who handles it=20
<br>> (in all likelihood), he doesn't need to know much more than th=
at the=20
<br>> operation failed. He doesn't need a string or a complex data s=
tructure=20
<br>> storing what happened. He knows exactly what he asked for, and he =
knows=20
<br>> exactly where it failed. All he needs to know is why.
<br>
<br>OTOH this is probably true *most* of the time. Not always. Say for
<br>example that the operation returning the expected was compiling a GLSL
<br>shader; the input is shader code, the output is a shader handle. But if
<br>something goes sideways, you probably want the compile log, which is in
<br>no way obvious just from knowing the input you fed the compile function=
..
<br>(I can come up with other, similar examples; generally where the
<br>function being called is "doing a lot".)<br></blockquote><div=
><br>True. But generally speaking, I would implement such a GLSL error obje=
ct by having the error object be able to fetch the log if the user wants it=
to do so. This means the error object would store a GLSL shader object han=
dle and will destroy it when the error object is destroyed.<br><br>This wou=
ld again be to avoid requiring a memory allocation in case of an error. If =
the user wants that memory allocation, they get to have it. But it shouldn&=
#39;t be forced on them just because shader compilation/linking failed.</di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_55_2006333581.1447341907997--
------=_Part_54_1250118934.1447341907997--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Thu, 12 Nov 2015 07:26:07 -0800 (PST)
Raw View
------=_Part_664_847471151.1447341967447
Content-Type: multipart/alternative;
boundary="----=_Part_665_827867184.1447341967448"
------=_Part_665_827867184.1447341967448
Content-Type: text/plain; charset=UTF-8
On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet Escriba
wrote:
>
> Hi,
>
> I would like to re-raise the expected discussion. Beside the conflicting
> part "managing errors in a different way", that should be covered by a
> specific paper, I would like to open the discussion in order to have a
> better proposal for expected.
>
> There were some concerns about the exception throw when there is no value.
> I'm wondering if we can do as for basic_string, we can have an error_traits
> that define which exception is thrown and that can also do conversion from
> exception to errors.
>
> basic_expected<T, Error=exception _ptr, Traits=error_traits<Error>>
>
> we could have a specialization for error_code/error_condition that would
> throw a system_error.
>
> What do you think of this customization?
>
Suggestion:
Instead of a trait class, if except<T, E> would raise an exception, call:
[[notreturn]] void std::rethrow(E&&e);
if E is one of std::exception_ptr, std::error_code then std::rethrow does
the obvious thing. For a generic E std::rethrow performs an unqualified
call to adl_rethrow(e). The default would just throw e.
It seems that adl calls are the preferred customization method with the
standard. The names are of course to be subjected to bikeshedding.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_665_827867184.1447341967448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet Escriba=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<font size=3D"+1">Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the
conflicting part "managing errors in a different way", that=
should
be covered by a specific paper, I would like to open the
discussion in order to have a better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is
no value. I'm wondering if we can do as for basic_string, we can
have an error_traits that define which exception is thrown and
that can also do conversion from exception to errors.<br>
<br>
basic_expected<T, Error=3Dexception _ptr,
Traits=3Derror_traits<Error>><br>
<br>
we could have a specialization for error_code/error_condition that
would throw a system_error.<br>
<br>
What do you think of this customization?<br>
</font></div></blockquote><div><br>Suggestion:<br><br>Instead of a tr=
ait class, if except<T, E> would raise an exception, call: <br><br>[[=
notreturn]] void std::rethrow(E&&e); <br><br>if E is one of std::ex=
ception_ptr, std::error_code then std::rethrow does the obvious thing. For =
a generic E std::rethrow performs an unqualified call to adl_rethrow(e). Th=
e default would just throw e.<br><br>It seems that adl calls are the prefer=
red customization method with the standard. The names are of course to be s=
ubjected to bikeshedding.<br><br><br>=C2=A0</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_665_827867184.1447341967448--
------=_Part_664_847471151.1447341967447--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 07:30:36 -0800 (PST)
Raw View
------=_Part_643_33927549.1447342236258
Content-Type: multipart/alternative;
boundary="----=_Part_644_572105947.1447342236258"
------=_Part_644_572105947.1447342236258
Content-Type: text/plain; charset=UTF-8
On Thursday, November 12, 2015 at 10:15:33 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-11 15:52, Tony V E wrote:
> > I'm not disagreeing, but the other example is vector<bool>.
> (Allocators,
> > vector<bool>, iostreams - things to be unfavourably compared to).
> >
> > I was unsure about expected<T, E> working differently when E is an
> > exception, vs when E is an int or any other error.
> > Particularly since in C++, almost anything can be thrown as an
> exception.
> > But we could define "is an exception" to be "derived from
> std::exception".
> > Or is exception_ptr. Or...
>
> What if expected had a method assert() that either does nothing (if
> expected has a value) or throws the error (if expected has an error)?
> *Maybe* this method would be conditionally enabled depending on if the
> error type is exception-like...
>
> ...Would that be a satisfactory compromise?
>
I suggested something like that earlier: `throw_if_error` (`assert` is of
course a macro). I think it would be acceptable, though I'm not sure I
would ever use it.
If the user calls it, it should throw E. The only time we would need an
exception to this is if E is `exception_ptr`; we'd want to rethrow that.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_644_572105947.1447342236258
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 10:15:33 AM UTC-5, Matthew Woehlke wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-11 15:52, Tony V E =
wrote:
<br>> I'm not disagreeing, but the other example is vector<bool&g=
t;. =C2=A0(Allocators,
<br>> vector<bool>, iostreams - things to be unfavourably compared=
to).
<br>>=20
<br>> I was unsure about expected<T, E> working differently when E=
is an
<br>> exception, vs when E is an int or any other error.
<br>> Particularly since in C++, almost anything can be thrown as an exc=
eption.
<br>> But we could define "is an exception" to be "derive=
d from std::exception".
<br>> Or is exception_ptr. Or...
<br>
<br>What if expected had a method assert() that either does nothing (if
<br>expected has a value) or throws the error (if expected has an error)?
<br>*Maybe* this method would be conditionally enabled depending on if the
<br>error type is exception-like...
<br>
<br>...Would that be a satisfactory compromise?
<br></blockquote><div><br>I suggested something like that earlier: `throw_i=
f_error` (`assert` is of course a macro). I think it would be acceptable, t=
hough I'm not sure I would ever use it.<br><br>If the user calls it, it=
should throw E. The only time we would need an exception to this is if E i=
s `exception_ptr`; we'd want to rethrow that.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_644_572105947.1447342236258--
------=_Part_643_33927549.1447342236258--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 19:09:42 +0100
Raw View
Le 12/11/2015 16:30, Nicol Bolas a =C3=A9crit :
> On Thursday, November 12, 2015 at 10:15:33 AM UTC-5, Matthew Woehlke wrot=
e:
>>
>> What if expected had a method assert() that either does nothing (if
>> expected has a value) or throws the error (if expected has an error)?
>> *Maybe* this method would be conditionally enabled depending on if the
>> error type is exception-like...
>>
>> ...Would that be a satisfactory compromise?
>>
> I suggested something like that earlier: `throw_if_error` (`assert` is of
> course a macro). I think it would be acceptable, though I'm not sure I
> would ever use it.
This function is implementable with the current interface. The user can=20
do it.
>
> If the user calls it, it should throw E. The only time we would need an
> exception to this is if E is `exception_ptr`; we'd want to rethrow that.
>
Hmm, it seems that not all want uniformity.
Would you like two classes with different behavior respect to the=20
exception throw?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 10:30:46 -0800 (PST)
Raw View
------=_Part_694_1189592304.1447353046390
Content-Type: multipart/alternative;
boundary="----=_Part_695_598742826.1447353046390"
------=_Part_695_598742826.1447353046390
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 1:09:46 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 12/11/2015 16:30, Nicol Bolas a =C3=A9crit :=20
> > On Thursday, November 12, 2015 at 10:15:33 AM UTC-5, Matthew Woehlke=20
> wrote:=20
> >>=20
> >> What if expected had a method assert() that either does nothing (if=20
> >> expected has a value) or throws the error (if expected has an error)?=
=20
> >> *Maybe* this method would be conditionally enabled depending on if the=
=20
> >> error type is exception-like...=20
> >>=20
> >> ...Would that be a satisfactory compromise?=20
> >>=20
> > I suggested something like that earlier: `throw_if_error` (`assert` is=
=20
> of=20
> > course a macro). I think it would be acceptable, though I'm not sure I=
=20
> > would ever use it.=20
> This function is implementable with the current interface. The user can=
=20
> do it.
>
The user could also implement `value` with just `operator*`, `operator=20
bool`, and `error()`. That doesn't mean they should have to.
=20
> >=20
> > If the user calls it, it should throw E. The only time we would need an=
=20
> > exception to this is if E is `exception_ptr`; we'd want to rethrow that=
..=20
> >=20
> Hmm, it seems that not all want uniformity.
>
`value` should have uniformity.
What any other prospective function does is up to that function and its=20
needs.
=20
> Would you like two classes with different behavior respect to the=20
> exception throw?
>
I don't know what you mean. Are you talking about two expected types?=20
Because that would be incredibly silly.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_695_598742826.1447353046390
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 1:09:46 PM UTC-5, Vicente J. Botet Escrib=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 12/11/2015 16:30, N=
icol Bolas a =C3=A9crit :
<br>> On Thursday, November 12, 2015 at 10:15:33 AM UTC-5, Matthew Woehl=
ke wrote:
<br>>>
<br>>> What if expected had a method assert() that either does nothin=
g (if
<br>>> expected has a value) or throws the error (if expected has an =
error)?
<br>>> *Maybe* this method would be conditionally enabled depending o=
n if the
<br>>> error type is exception-like...
<br>>>
<br>>> ...Would that be a satisfactory compromise?
<br>>>
<br>> I suggested something like that earlier: `throw_if_error` (`assert=
` is of
<br>> course a macro). I think it would be acceptable, though I'm no=
t sure I
<br>> would ever use it.
<br>This function is implementable with the current interface. The user can=
=20
<br>do it.<br></blockquote><div><br>The user could also implement `value` w=
ith just `operator*`, `operator bool`, and `error()`. That doesn't mean=
they should have to.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">>
<br>> If the user calls it, it should throw E. The only time we would ne=
ed an
<br>> exception to this is if E is `exception_ptr`; we'd want to ret=
hrow that.
<br>>
<br>Hmm, it seems that not all want uniformity.<br></blockquote><div><br>`v=
alue` should have uniformity.<br><br>What any other prospective function do=
es is up to that function and its needs.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
Would you like two classes with different behavior respect to the=20
<br>exception throw?<br></blockquote><div><br>I don't know what you mea=
n. Are you talking about two expected types? Because that would be incredib=
ly silly. <br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_695_598742826.1447353046390--
------=_Part_694_1189592304.1447353046390--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 19:47:18 +0100
Raw View
Le 12/11/2015 16:14, Nicol Bolas a =C3=A9crit :
> On Wednesday, November 11, 2015 at 6:19:03 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Le 12/11/2015 00:00, Nicol Bolas a =C3=A9crit :
>>>
>>>>
>>> The last expected proposal was over a year ago. I don't know why you
>> would
>>> expect everyone to be familiar with every aspect of its design.
>>>
>>> That being said, why not have a `throw_if_error` function that actually
>>> throws `E` (or throws the exception contained in an `exception_ptr`)?
>> We have already it value().
>>
> `value` access the value; throwing an exception is part of the interface,
> but it's not the purpose of the function. Furthermore, because
> `throw_if_error` is a different function, it can reasonably be given
> different semantics. So `value` would always throw some form of
> `bad_expected` or whatever. While `throw_if_error` would throw E, or
> rethrow an `exception_ptr`.
Sorry, I misunderstood the intent. The user can create its own throw=20
if_error with the current interface. I don't see the need to add it to=20
the interface.
We could say the same for value, but I believe that getting the value or=20
throw is something the user could need more often.
>> =20
>>>>> Also, we don't want to overburden `expected` with customization
>>>> machinery.
>>>>> Not unless there's a really good reason. I don't want to have to hunt
>>>> down
>>>>> some traits class to see what I should have to catch. Throwing the
>> error
>>>>> code type itself, whatever that type is, should be sufficient for a
>>>>> function like `throw_if_error`.
>>>> Please, refer to the proposal. Do you mean that expected<T,E>::value()
>>>> should throw an exception E?
>>>> What about expected<T,exception_ptr>, should throw an exception_ptr?
>>>>
>>>> After all, I've always felt that the point of `expected` was to *not*
>> use
>>>>> exceptions, to have an alternative to them.
>>>> Some could make this use, but expected works very well with exceptions=
..
>>>> There is no either you use exceptions or you use expected decision to
>>>> make.
>>>>
>>> But there is such a decision to make. I recall a discussion about this.
>>>
>>> If `expected` holds an `exception_ptr`, then the only useful thing a
>> user
>>> can do with that is throw it. They can't test it. They can't print it.
>> They
>>> can only throw it and catch the result. That makes for a useless error
>> code
>>> value, so I seriously doubt anyone will use it as such.
>> I will use it as the underlying type for future e.g.
>>
> Do you mean like `future<expected<T, exception_ptr>>`?
No. I mean that the storage of future can be expected<T>. Sorry I used=20
underlying instead of storage.
> Why would you *ever*
> want to do that? Promise/future already has a perfectly reasonable way to
> pass exceptions through it. If this were 2009 and promise/future were sti=
ll
> on the drawing board, maybe. But now that they've had exception transfer
> machinery for years? There's just no point to this.
>
>>> In short, you're not going to see a lot of `expected<T, exception_ptr>`=
..
>> It
>>> just doesn't make sense. You may as well have just thrown the exception
>>> directly. After all, the *only way* to create an `exception_ptr` is to
>>> throw an exception, so you've already paid the price one time. There is
>>> absolutely no reason to catch an exception, package it into an
>> `expected<T,
>>> exception_ptr>`, and then give it to someone who's *only useful option*
>> is
>>> to throw it again.
>> There are other worlds where we want to use it.
>>> Throwing exceptions isn't cheap. That's a cost that needs to be paid at
>>> most once.
>> Not if the exception was already thrown independently of whether you
>> will store it in expected or rethrow it.
>>> If I'm writing a function that can fail, I can choose to signal that
>>> failure in one of two ways: exception or expected. If I use `expected`,
>>> then I have to choose what to return in the case of failure. Returning =
a
>>> big object bloats the return value, so I have an incentive to minimize
>> the
>>> error data. And because the direct caller will be the one who handles i=
t
>>> (in all likelihood), he doesn't need to know much more than that the
>>> operation failed. He doesn't need a string or a complex data structure
>>> storing what happened. He knows exactly what he asked for, and he knows
>>> exactly where it failed. All he needs to know is why.
>> Function that return expected can call other functions that throw
>> exceptions, isn't it?
>>
> OK, there are generally two kinds of users who will use `expected`. There
> are those who prefer local exception handling, either in a particular few
> cases or as a general rule. And there are those who simply *cannot* use
> exceptions.
>
> If you call a function that throws, you are obviously not in the latter
> category. Which means that your code is perfectly capable of handling
> exceptions. So just... *do that*. If your function is not going to actual=
ly
> handle the exception, just let it propagate through up to whomever really
> is going to handle it.
Well, I want to define a function that return expected and call other=20
function that throw. I want to store these possible exception in=20
expected. What is the problem?
>
> The only time I could see `expected<T, exception_ptr>` possibly being
> useful would be for passage of an exception through a C library. Of cours=
e,
> how you pass that C++ type through C at all is an open question. And even
> this is a rare case. It should certainly be allowed, but it shouldn't be
> common enough to have special case handling for `expected` when it holds =
an
> `exception_ptr`.
Don't use expected<T> when it is not useful to you.
> =20
>
>>> If I throw an exception, I *must* assume that the person catching it ma=
y
>>> have very little information about the particulars of the call that
>> caused
>>> it. Therefore, my exception must store a lot of data, so that the
>> receiver
>>> can know what to do with it.
>>>
>>> Notice how the FileSystem TS's exception type holds rich data, while th=
e
>>> error code is just a number.
>>>
>>> Emitting an exception is a heavy-weight operation, so making it slightl=
y
>>> heavier by returning rich data is fine. Returning an expected is a
>>> light-weight operation, so making it heavier is a bad thing. We should
>> not
>>> confuse the two and try to treat expected as some kind of precursor to
>> an
>>> exception.
>> I don't believe I'm confusing the two?
>>
> And yet, that's what your entire post here has been. You frequently talk
> about converting exceptions into expected and vice-versa. These are two
> separate and distinct error mechanisms.
Agreed.
>
> This is also something I recall we discussed. You effectively wanted to
> have API interfaces return `expected` objects by default. But you wanted =
to
> allow users to decide whether to use exceptions by having them call
> `value`, so these objects would be `expected<T, exception_ptr>`. And with
> the rethrow behavior you wanted in `value`, you would get the exception y=
ou
> would normally expect from the API.
>
> That's confusing the two error mechanisms. By returning `expected<T,
> exception_ptr>`, you effectively limit the usefulness of that API. Users
> who operate in fields where exceptions are not allowed *cannot* use your
> API, because if exceptions aren't allowed, odds are good that the memory
> allocations needed for `make_exception_ptr` aren't allowed either. Even
> users who simply choose not to use exceptions lose with such an interface=
..
> Because all they get for an error code is an opaque pointer, not an error
> code that they could use to see *why* an operation failed.
How to say, I can write my own function that return expected<T> without=20
worrying about a 3pp that couldn't use my code because it doesn't use=20
exceptions. People write more application code than library code.
>
> Or at least, not without throwing it. A thing they were specifically tryi=
ng
> to avoid.
Some want to avoid exception and expected will work for them. They=20
should just not use the operations that throw ,ad of course don't use=20
expected<T, exception_ptr>. I don't see the problem.
> You may as well have given them `expected<T, monostate>`. At
> least then, they wouldn't get an unnecessary memory allocation.
I don't need to give them that. It is up to the user to use whatever=20
they want.
>
> APIs that use `expected` should not look like APIs that would throw
> exceptions. And a user who calls the `expected` form does not generally
> want to transform it into an exception.
Well, it seems that you have a good experience with expected. What=20
people do is out of the scope of the standard.
>
> I'm fine with `value` throwing; it fits with other similar types (optiona=
l,
> etc). What I'm against is the idea that we should dynamically switch
> between expected and exceptions, that they should be equated and easily
> inter-operable.
Why?
> =20
>
>>> =20
>>>
>>>>> It seems kinda silly to add a
>>>>> customization point solely for exception behavior, when that's exactl=
y
>>>> what
>>>>> you're trying to avoid.
>>>>>
>>>> It seems that you don't understand the purpose of expected.
>>> I understand what *I want* from expected.
>> If you know what you want, the best we can do is to write a proposal ;-)
>>> You seem to think of it as some
>>> functional programming gizmo or some way of passing exceptions around.
>> For
>>> me, it's an *alternative* mechanism of error reporting that is biased
>>> towards local error handling rather than non-local handling.
>> You are right, expected is a error reporting mechanism that needs local
>> error handling. However the await proposal gives him a transparent
>> non-local erro reporting.
>
> If you have to annotate every propagation of an error with `await`, it's
> not "transparent".
It is better than adding a check :)
> If you have to modify your return value, it's not
> "transparent".
I don't need to modify it. I want to return expected.
> If you can't pass different kinds of error codes without
> even more modifications to your return value (`expected<T, variant<E1, E2=
,
> ...>>`), it's not "transparent".
Hmm, I was expecting this ;-) Do you want to return expected<T,=20
variant<E1, E2, ...>>?
Do you want to return expected <T,E>? you can also. You could even=20
return expected <T,any>.
> And if functions that use this syntax
> can't also use futures or other forms of `await`, it's not "transparent".
You can use futures, but I believe that you can not use await on them=20
transparently. We need to know what this mean.
>
> Hijacking `await` machinery has consequences. And those consequences are
> far from "transparent" to the user. I would personally much rather you ju=
st
> use the right error mechanism. If you want local handling, call the API
> that returns `expected`. If you want non-local handling, call the API tha=
t
> throws.
I see that you don't want await on expected. Maybe you will change once=20
every one is using it.
> =20
>
>> Since the original proposal there was some
>> kind of do-notation that simplified the error reporting. Now we ave
>> await :)
>>> =20
>>>
>>>> If proposed
>>>> expected is able to throw an exception when there is no value. That's
>> it.
>>>> The question is which exception.
>>>>
>>> And I said "it seems kinda silly to *add a customization point solely
>> for
>>> exception behavior*, when that's exactly what you're trying to avoid."
>> So
>>> on the matter of customizable exceptions, I say no.
>>>
>> It is the fist time someone has said that. Now you and Mat say that we
>> don't need to throw any exception.
>
> I never said that `value` shouldn't throw. Indeed, I said quite the
> opposite: "it should throw the same exception from every `expected` objec=
t."
Maybe I confused with other. I will check it.
>
> But please keep in mind Study Group 14. These are people who cannot use
> exceptions. People who cannot have objects randomly allocating memory. Bu=
t
> they are also people who need a good alternative error handling mechanism=
,
> one that can be added to standard library interfaces so that they can use
> them in lieu of the exception versions.
I don't see how anything I'm proposing couldn't be used by SG14.
>
> `expected` is exactly what they're looking for. If `value` throws, that's
> fine; they can just avoid calling it. But they need to be able to have an
> alternative error mechanism that can be standardized. You should probably
> get with those guys, because they could probably help `expected` get push=
ed
> forward. It's exactly the sort of thing they want.
I know this.
>
> Oh, and one more thing. `expected` is, functionally speaking, a kind of
> never-empty variant with a specialized interface. So I'm curious as to
> exactly how you solve the various issues that surrounded the more
> generalized `variant` class. It's not clear from your current proposal ho=
w
> you can provide the exception guarantees that it claims.
Hmm, I was expecting that also ;-) But SG14 would not be concerned by=20
the possible issue, isn't it?
expected<T,E> would behaves like variant<T,E> in a lot of cases, and I=20
would re-implement it using variant<T,E> as storage.
Please, start a new thread to discuss the exception safety concern.
>
> For example, on copy-assignment from another `expected`, you say that if
> the copy constructor for the type in the source expected fails, "no
> effect". How do you implement that if `T` or `E` is not nothrow
> copy/moveable? Do you double-buffer?
>
> I suggest you take a look at the current P0088 variant proposal and
> investigate the issues that prompted it to get an `invalid` state. Becaus=
e
> `expected` only has two types, and one of them is an error type, you coul=
d
> probably impose more restrictive requirements on E that make it possible =
to
> implement your guarantees. For example, you could require that E is nothr=
ow
> moveable, which makes it possible to implement your guarantees without
> double-buffering.
>
Thanks for the suggestion.
Maybe you understand now why expected was frozen during 1 year.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 19:56:58 +0100
Raw View
Le 12/11/2015 19:30, Nicol Bolas a =C3=A9crit :
> On Thursday, November 12, 2015 at 1:09:46 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Le 12/11/2015 16:30, Nicol Bolas a =C3=A9crit :
>>> On Thursday, November 12, 2015 at 10:15:33 AM UTC-5, Matthew Woehlke
>> wrote:
>>>> What if expected had a method assert() that either does nothing (if
>>>> expected has a value) or throws the error (if expected has an error)?
>>>> *Maybe* this method would be conditionally enabled depending on if the
>>>> error type is exception-like...
>>>>
>>>> ...Would that be a satisfactory compromise?
>>>>
>>> I suggested something like that earlier: `throw_if_error` (`assert` is
>> of
>>> course a macro). I think it would be acceptable, though I'm not sure I
>>> would ever use it.
>> This function is implementable with the current interface. The user can
>> do it.
>>
> The user could also implement `value` with just `operator*`, `operator
> bool`, and `error()`. That doesn't mean they should have to.
I know, and I find value useful, but don't for throw_if_error.
> =20
>
>>> If the user calls it, it should throw E. The only time we would need an
>>> exception to this is if E is `exception_ptr`; we'd want to rethrow that=
..
>>>
>> Hmm, it seems that not all want uniformity.
>>
> `value` should have uniformity.
And throw_if_error, not?
>
> What any other prospective function does is up to that function and its
> needs.
> =20
>
>> Would you like two classes with different behavior respect to the
>> exception throw?
>>
> I don't know what you mean. Are you talking about two expected types?
> Because that would be incredibly silly.
>
Yes, I believed you were talking of value. Sorry. I see that you are not=20
for :(
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 20:05:48 +0100
Raw View
Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :
> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet Escri=
ba
> wrote:
>> Hi,
>>
>> I would like to re-raise the expected discussion. Beside the conflicting
>> part "managing errors in a different way", that should be covered by a
>> specific paper, I would like to open the discussion in order to have a
>> better proposal for expected.
>>
>> There were some concerns about the exception throw when there is no valu=
e.
>> I'm wondering if we can do as for basic_string, we can have an error_tra=
its
>> that define which exception is thrown and that can also do conversion fr=
om
>> exception to errors.
>>
>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>>
>>
>> we could have a specialization for error_code/error_condition that would
>> throw a system_error.
>>
>> What do you think of this customization?
>>
> Suggestion:
>
> Instead of a trait class, if except<T, E> would raise an exception, call:
>
> [[notreturn]] void std::rethrow(E&&e);
We have rethrow_exception. Are you talking of a new function?
>
> if E is one of std::exception_ptr, std::error_code then std::rethrow does
> the obvious thing.
That is, ...
> For a generic E std::rethrow performs an unqualified
> call to adl_rethrow(e). The default would just throw e.
>
> It seems that adl calls are the preferred customization method with the
> standard. The names are of course to be subjected to bikeshedding.
>
I don't mind how we customize the behavior. However, it seems that there=20
are some people that are against customizing the exception to throw.
I would like to hear from those that would need to customize the behavior.
What others think of customizing rethrow or rethrow_exception?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 12:06:32 -0800 (PST)
Raw View
------=_Part_9412_1805406315.1447358793070
Content-Type: multipart/alternative;
boundary="----=_Part_9413_103230049.1447358793071"
------=_Part_9413_103230049.1447358793071
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 1:47:22 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 12/11/2015 16:14, Nicol Bolas a =C3=A9crit :=20
> > On Wednesday, November 11, 2015 at 6:19:03 PM UTC-5, Vicente J. Botet=
=20
> > Escriba wrote:=20
> >> Le 12/11/2015 00:00, Nicol Bolas a =C3=A9crit :=20
> > Why would you *ever*=20
> > want to do that? Promise/future already has a perfectly reasonable way=
=20
> to=20
> > pass exceptions through it. If this were 2009 and promise/future were=
=20
> still=20
> > on the drawing board, maybe. But now that they've had exception transfe=
r=20
> > machinery for years? There's just no point to this.=20
> >=20
> >>> In short, you're not going to see a lot of `expected<T,=20
> exception_ptr>`.=20
> >> It=20
> >>> just doesn't make sense. You may as well have just thrown the=20
> exception=20
> >>> directly. After all, the *only way* to create an `exception_ptr` is t=
o=20
> >>> throw an exception, so you've already paid the price one time. There=
=20
> is=20
> >>> absolutely no reason to catch an exception, package it into an=20
> >> `expected<T,=20
> >>> exception_ptr>`, and then give it to someone who's *only useful=20
> option*=20
> >> is=20
> >>> to throw it again.=20
> >> There are other worlds where we want to use it.=20
> >>> Throwing exceptions isn't cheap. That's a cost that needs to be paid=
=20
> at=20
> >>> most once.=20
> >> Not if the exception was already thrown independently of whether you=
=20
> >> will store it in expected or rethrow it.=20
> >>> If I'm writing a function that can fail, I can choose to signal that=
=20
> >>> failure in one of two ways: exception or expected. If I use=20
> `expected`,=20
> >>> then I have to choose what to return in the case of failure. Returnin=
g=20
> a=20
> >>> big object bloats the return value, so I have an incentive to minimiz=
e=20
> >> the=20
> >>> error data. And because the direct caller will be the one who handles=
=20
> it=20
> >>> (in all likelihood), he doesn't need to know much more than that the=
=20
> >>> operation failed. He doesn't need a string or a complex data structur=
e=20
> >>> storing what happened. He knows exactly what he asked for, and he=20
> knows=20
> >>> exactly where it failed. All he needs to know is why.=20
> >> Function that return expected can call other functions that throw=20
> >> exceptions, isn't it?=20
> >>=20
> > OK, there are generally two kinds of users who will use `expected`.=20
> There=20
> > are those who prefer local exception handling, either in a particular=
=20
> few=20
> > cases or as a general rule. And there are those who simply *cannot* use=
=20
> > exceptions.=20
> >=20
> > If you call a function that throws, you are obviously not in the latter=
=20
> > category. Which means that your code is perfectly capable of handling=
=20
> > exceptions. So just... *do that*. If your function is not going to=20
> actually=20
> > handle the exception, just let it propagate through up to whomever=20
> really=20
> > is going to handle it.=20
> Well, I want to define a function that return expected and call other=20
> function that throw. I want to store these possible exception in=20
> expected. What is the problem?
>
You seem to keep missing the important question: why?
Why do you want to store those exceptions *instead* of letting them=20
propagate up the stack? It can't be because you're working in code that=20
can't handle exceptions. So what reason would you have for pre-emptively=20
catching them and sticking them in an opaque object?
What good will it do to the *caller* of your function to get an=20
`exception_ptr` instead of a real error?
You are too focused on what you want and not enough on what the user of=20
your type will *need*. What will users who get an `expected<T,=20
exception_ptr>` do with it? You're returning an error to them so that they=
=20
can resolve the error condition. How will `exception_ptr` help them do so?
> >=20
> > The only time I could see `expected<T, exception_ptr>` possibly being=
=20
> > useful would be for passage of an exception through a C library. Of=20
> course,=20
> > how you pass that C++ type through C at all is an open question. And=20
> even=20
> > this is a rare case. It should certainly be allowed, but it shouldn't b=
e=20
> > common enough to have special case handling for `expected` when it hold=
s=20
> an=20
> > `exception_ptr`.=20
> Don't use expected<T> when it is not useful to you.
>
Return values are defined by the function being called, not by what is=20
"useful to you". So if someone returns an `expected<T, exception_ptr>`,=20
that's something everyone has to deal with.
I'm not saying that there is no use to the construct or that it should be=
=20
forbidden. But I would strongly advise you not to think that `expected<T,=
=20
exception_ptr>` will be the default case for users of `expected`. Or even=
=20
the common case.
> =20
> >=20
> >>> If I throw an exception, I *must* assume that the person catching it=
=20
> may=20
> >>> have very little information about the particulars of the call that=
=20
> >> caused=20
> >>> it. Therefore, my exception must store a lot of data, so that the=20
> >> receiver=20
> >>> can know what to do with it.=20
> >>>=20
> >>> Notice how the FileSystem TS's exception type holds rich data, while=
=20
> the=20
> >>> error code is just a number.=20
> >>>=20
> >>> Emitting an exception is a heavy-weight operation, so making it=20
> slightly=20
> >>> heavier by returning rich data is fine. Returning an expected is a=20
> >>> light-weight operation, so making it heavier is a bad thing. We shoul=
d=20
> >> not=20
> >>> confuse the two and try to treat expected as some kind of precursor t=
o=20
> >> an=20
> >>> exception.=20
> >> I don't believe I'm confusing the two?=20
> >>=20
> > And yet, that's what your entire post here has been. You frequently tal=
k=20
> > about converting exceptions into expected and vice-versa. These are two=
=20
> > separate and distinct error mechanisms.=20
> Agreed.
>
Then we must not agree on what "separate and distinct" mean. To me, that=20
means "things that are not the same and should not be equated".
>=20
> > This is also something I recall we discussed. You effectively wanted to=
=20
> > have API interfaces return `expected` objects by default. But you wante=
d=20
> to=20
> > allow users to decide whether to use exceptions by having them call=20
> > `value`, so these objects would be `expected<T, exception_ptr>`. And=20
> with=20
> > the rethrow behavior you wanted in `value`, you would get the exception=
=20
> you=20
> > would normally expect from the API.=20
> >=20
> > That's confusing the two error mechanisms. By returning `expected<T,=20
> > exception_ptr>`, you effectively limit the usefulness of that API. User=
s=20
> > who operate in fields where exceptions are not allowed *cannot* use you=
r=20
> > API, because if exceptions aren't allowed, odds are good that the memor=
y=20
> > allocations needed for `make_exception_ptr` aren't allowed either. Even=
=20
> > users who simply choose not to use exceptions lose with such an=20
> interface.=20
> > Because all they get for an error code is an opaque pointer, not an=20
> error=20
> > code that they could use to see *why* an operation failed.=20
> How to say, I can write my own function that return expected<T> without=
=20
> worrying about a 3pp that couldn't use my code because it doesn't use=20
> exceptions. People write more application code than library code.=20
>
Nobody will be unable to use your code because it *doesn't* use exceptions.=
=20
You don't see people shying away from stoi and so forth just because they=
=20
don't report errors as exceptions. People don't avoid iostreams just=20
because they don't use exceptions (by default). Users may not like it, or=
=20
they may wrap it in a throwing interface if they're really anal about that=
=20
sort of thing. But generally speaking, they'll use what you provide based=
=20
on whether it's good functionality, not based on your error reporting=20
scheme.
And if `expected` were a standard library type, they'd be even more willing=
=20
to use code that uses it.
So I don't see a need for any kind of convergence between exceptions and=20
`expected`.
> APIs that use `expected` should not look like APIs that would throw=20
> > exceptions. And a user who calls the `expected` form does not generally=
=20
> > want to transform it into an exception.=20
> Well, it seems that you have a good experience with expected. What=20
> people do is out of the scope of the standard.
>
No, it is very much a matter of the standard. They don't just stick things=
=20
into the language/library and expect people to do whatever with them.=20
Features are added because they are expected to make things easier for=20
users. So no, what people do with it is very much a part of why something=
=20
should be standardized.
And however much you may see `expected` as some monadic functional=20
whatever, to most people it is "a good way to handle errors without=20
exceptions". Just as `await` is not "do notation" or somesuch; it's a way=
=20
to schedule the continuation of a function.
=20
> > I'm fine with `value` throwing; it fits with other similar types=20
> (optional,=20
> > etc). What I'm against is the idea that we should dynamically switch=20
> > between expected and exceptions, that they should be equated and easily=
=20
> > inter-operable.=20
> Why?
>
I explained this very carefully, but you ignored it. I explained how=20
`exception_ptr` carries no useful semantic information about the error, and=
=20
therefore returning `expected<T, exception_ptr>` is substantially less=20
useful to most users than returning `expected<T, some_error_type>`. I=20
explained how many of the people who are interested in `expected` are=20
people who *cannot use exceptions*, and therefore cannot use `expected<T,=
=20
exception_ptr>`, since they cannot rethrow it.
So you should explain why a user would want a function to return=20
`expected<T, exception_ptr>`. Explain why a user would want that and what=
=20
they would expect to do with it in the event of an error. Why do we need=20
special interoperation functionality between expected and exceptions?
> If you have to annotate every propagation of an error with `await`, it's=
=20
> > not "transparent".=20
> It is better than adding a check :)=20
>
Considering the various machinery and compilation gymnastics needed to make=
=20
`await expected` work, I wouldn't be too sure about that. At the very=20
least, you have yet to *prove* what the full consequences will be relative=
=20
to doing it manually.
> If you have to modify your return value, it's not=20
> > "transparent".=20
> I don't need to modify it. I want to return expected.=20
> > If you can't pass different kinds of error codes without=20
> > even more modifications to your return value (`expected<T, variant<E1,=
=20
> E2,=20
> > ...>>`), it's not "transparent".=20
> Hmm, I was expecting this ;-) Do you want to return expected<T,=20
> variant<E1, E2, ...>>?=20
> Do you want to return expected <T,E>? you can also. You could even=20
> return expected <T,any>.
>
Of course, the best way to encapsulate an error is by allocating memory. /s
Every attempt you produce to help make `expected` better at non-local error=
=20
handling only validates the current design for exceptions *more*. When you=
=20
have to invent new syntax and pervert the meaning of a keyword in the=20
language, that should be a sign that you're doing error handling wrong.
`expected` should be for immediate handling of the error. If someone else=
=20
is going to handle it, you should have thrown an exception instead of=20
returning `expected`.
> And if functions that use this syntax=20
> > can't also use futures or other forms of `await`, it's not=20
> "transparent".=20
> You can use futures, but I believe that you can not use await on them=20
> transparently. We need to know what this mean.=20
>
> >=20
> > Hijacking `await` machinery has consequences. And those consequences ar=
e=20
> > far from "transparent" to the user. I would personally much rather you=
=20
> just=20
> > use the right error mechanism. If you want local handling, call the API=
=20
> > that returns `expected`. If you want non-local handling, call the API=
=20
> that=20
> > throws.=20
> I see that you don't want await on expected. Maybe you will change once=
=20
> every one is using it.
>
Oh, I'm sure Bjarne Stroustrup is waiting with baited breath to add "use=20
await with expected" and "favor expected over exceptions" to the core=20
guidelines. /s
>=20
> > But please keep in mind Study Group 14. These are people who cannot use=
=20
> > exceptions. People who cannot have objects randomly allocating memory.=
=20
> But=20
> > they are also people who need a good alternative error handling=20
> mechanism,=20
> > one that can be added to standard library interfaces so that they can=
=20
> use=20
> > them in lieu of the exception versions.=20
> I don't see how anything I'm proposing couldn't be used by SG14.
>
Every time you say that `expected<T, exception_ptr>` is useful, every time=
=20
you think that there should be convergence between exceptions and expected,=
=20
you are talking about something that cannot be used by SG14.
>=20
> > `expected` is exactly what they're looking for. If `value` throws,=20
> that's=20
> > fine; they can just avoid calling it. But they need to be able to have=
=20
> an=20
> > alternative error mechanism that can be standardized. You should=20
> probably=20
> > get with those guys, because they could probably help `expected` get=20
> pushed=20
> > forward. It's exactly the sort of thing they want.=20
> I know this.=20
> >=20
> > Oh, and one more thing. `expected` is, functionally speaking, a kind of=
=20
> > never-empty variant with a specialized interface. So I'm curious as to=
=20
> > exactly how you solve the various issues that surrounded the more=20
> > generalized `variant` class. It's not clear from your current proposal=
=20
> how=20
> > you can provide the exception guarantees that it claims.=20
> Hmm, I was expecting that also ;-) But SG14 would not be concerned by=20
> the possible issue, isn't it?
>
That's why I said "one more thing". That was a change of topic.
>=20
> > For example, on copy-assignment from another `expected`, you say that i=
f=20
> > the copy constructor for the type in the source expected fails, "no=20
> > effect". How do you implement that if `T` or `E` is not nothrow=20
> > copy/moveable? Do you double-buffer?=20
> >=20
> > I suggest you take a look at the current P0088 variant proposal and=20
> > investigate the issues that prompted it to get an `invalid` state.=20
> Because=20
> > `expected` only has two types, and one of them is an error type, you=20
> could=20
> > probably impose more restrictive requirements on E that make it possibl=
e=20
> to=20
> > implement your guarantees. For example, you could require that E is=20
> nothrow=20
> > moveable, which makes it possible to implement your guarantees without=
=20
> > double-buffering.=20
> >=20
> Thanks for the suggestion.=20
> Maybe you understand now why expected was frozen during 1 year.
>
If you were honestly waiting for variant's design to be finished before=20
updating your proposal, that was a bad idea on your part. All the issues=20
brought up in the variant discussions were applicable to `expected`, so you=
=20
shouldn't have been sitting on the sidelines. Because the current=20
possibly-invalid design we have arrived at is not reasonable for `expected`=
..
`expected`, despite being similar to a `variant`, is a different class with=
=20
different needs. So its design should not have been dependent on the=20
outcome of the various `variant` proposals.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_9413_103230049.1447358793071
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 1:47:22 PM UTC-5, Vicente J. Botet Escrib=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 12/11/2015 16:14, N=
icol Bolas a =C3=A9crit :
<br>> On Wednesday, November 11, 2015 at 6:19:03 PM UTC-5, Vicente J. Bo=
tet
<br>> Escriba wrote:
<br>>> Le 12/11/2015 00:00, Nicol Bolas a =C3=A9crit :
<br>> Why would you *ever*
<br>> want to do that? Promise/future already has a perfectly reasonable=
way to
<br>> pass exceptions through it. If this were 2009 and promise/future w=
ere still
<br>> on the drawing board, maybe. But now that they've had exceptio=
n transfer
<br>> machinery for years? There's just no point to this.
<br>>
<br>>>> In short, you're not going to see a lot of `expected&l=
t;T, exception_ptr>`.
<br>>> It
<br>>>> just doesn't make sense. You may as well have just thr=
own the exception
<br>>>> directly. After all, the *only way* to create an `exceptio=
n_ptr` is to
<br>>>> throw an exception, so you've already paid the price o=
ne time. There is
<br>>>> absolutely no reason to catch an exception, package it int=
o an
<br>>> `expected<T,
<br>>>> exception_ptr>`, and then give it to someone who's =
*only useful option*
<br>>> is
<br>>>> to throw it again.
<br>>> There are other worlds where we want to use it.
<br>>>> Throwing exceptions isn't cheap. That's a cost tha=
t needs to be paid at
<br>>>> most once.
<br>>> Not if the exception was already thrown independently of wheth=
er you
<br>>> will store it in expected or rethrow it.
<br>>>> If I'm writing a function that can fail, I can choose =
to signal that
<br>>>> failure in one of two ways: exception or expected. If I us=
e `expected`,
<br>>>> then I have to choose what to return in the case of failur=
e. Returning a
<br>>>> big object bloats the return value, so I have an incentive=
to minimize
<br>>> the
<br>>>> error data. And because the direct caller will be the one =
who handles it
<br>>>> (in all likelihood), he doesn't need to know much more=
than that the
<br>>>> operation failed. He doesn't need a string or a comple=
x data structure
<br>>>> storing what happened. He knows exactly what he asked for,=
and he knows
<br>>>> exactly where it failed. All he needs to know is why.
<br>>> Function that return expected can call other functions that th=
row
<br>>> exceptions, isn't it?
<br>>>
<br>> OK, there are generally two kinds of users who will use `expected`=
.. There
<br>> are those who prefer local exception handling, either in a particu=
lar few
<br>> cases or as a general rule. And there are those who simply *cannot=
* use
<br>> exceptions.
<br>>
<br>> If you call a function that throws, you are obviously not in the l=
atter
<br>> category. Which means that your code is perfectly capable of handl=
ing
<br>> exceptions. So just... *do that*. If your function is not going to=
actually
<br>> handle the exception, just let it propagate through up to whomever=
really
<br>> is going to handle it.
<br>Well, I want to define a function that return expected and call other=
=20
<br>function that throw. I want to store these possible exception in=20
<br>expected. What is the problem?<br></blockquote><div><br>You seem to kee=
p missing the important question: why?<br><br>Why do you want to store thos=
e exceptions <i>instead</i> of letting them propagate up the stack? It can&=
#39;t be because you're working in code that can't handle exception=
s. So what reason would you have for pre-emptively catching them and sticki=
ng them in an opaque object?<br><br>What good will it do to the <i>caller</=
i> of your function to get an `exception_ptr` instead of a real error?<br><=
br>You are too focused on what you want and not enough on what the user of =
your type will <i>need</i>. What will users who get an `expected<T, exce=
ption_ptr>` do with it? You're returning an error to them so that th=
ey can resolve the error condition. How will `exception_ptr` help them do s=
o?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>>
<br>> The only time I could see `expected<T, exception_ptr>` possi=
bly being
<br>> useful would be for passage of an exception through a C library. O=
f course,
<br>> how you pass that C++ type through C at all is an open question. A=
nd even
<br>> this is a rare case. It should certainly be allowed, but it should=
n't be
<br>> common enough to have special case handling for `expected` when it=
holds an
<br>> `exception_ptr`.
<br>Don't use expected<T> when it is not useful to you.<br></bloc=
kquote><div><br>Return values are defined by the function being called, not=
by what is=20
"useful to you". So if someone returns an `expected<T,=20
exception_ptr>`, that's something everyone has to deal with.<br><br>=
I'm not saying that there is no use to the construct or that it should =
be forbidden. But I would strongly advise you not to think that `expected&l=
t;T, exception_ptr>` will be the default case for users of `expected`. O=
r even the common case.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">> =C2=A0=20
<br>>
<br>>>> If I throw an exception, I *must* assume that the person c=
atching it may
<br>>>> have very little information about the particulars of the =
call that
<br>>> caused
<br>>>> it. Therefore, my exception must store a lot of data, so t=
hat the
<br>>> receiver
<br>>>> can know what to do with it.
<br>>>>
<br>>>> Notice how the FileSystem TS's exception type holds ri=
ch data, while the
<br>>>> error code is just a number.
<br>>>>
<br>>>> Emitting an exception is a heavy-weight operation, so maki=
ng it slightly
<br>>>> heavier by returning rich data is fine. Returning an expec=
ted is a
<br>>>> light-weight operation, so making it heavier is a bad thin=
g. We should
<br>>> not
<br>>>> confuse the two and try to treat expected as some kind of =
precursor to
<br>>> an
<br>>>> exception.
<br>>> I don't believe I'm confusing the two?
<br>>>
<br>> And yet, that's what your entire post here has been. You frequ=
ently talk
<br>> about converting exceptions into expected and vice-versa. These ar=
e two
<br>> separate and distinct error mechanisms.
<br>Agreed.<br></blockquote><div><br>Then we must not agree on what "s=
eparate and distinct" mean. To me, that means "things that are no=
t the same and should not be equated".<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">>
<br>> This is also something I recall we discussed. You effectively want=
ed to
<br>> have API interfaces return `expected` objects by default. But you =
wanted to
<br>> allow users to decide whether to use exceptions by having them cal=
l
<br>> `value`, so these objects would be `expected<T, exception_ptr&g=
t;`. And with
<br>> the rethrow behavior you wanted in `value`, you would get the exce=
ption you
<br>> would normally expect from the API.
<br>>
<br>> That's confusing the two error mechanisms. By returning `expec=
ted<T,
<br>> exception_ptr>`, you effectively limit the usefulness of that A=
PI. Users
<br>> who operate in fields where exceptions are not allowed *cannot* us=
e your
<br>> API, because if exceptions aren't allowed, odds are good that =
the memory
<br>> allocations needed for `make_exception_ptr` aren't allowed eit=
her. Even
<br>> users who simply choose not to use exceptions lose with such an in=
terface.
<br>> Because all they get for an error code is an opaque pointer, not a=
n error
<br>> code that they could use to see *why* an operation failed.
<br>How to say, I can write my own function that return expected<T> w=
ithout=20
<br>worrying about a 3pp that couldn't use my code because it doesn'=
;t use=20
<br>exceptions. People write more application code than library code.
<br></blockquote><div><br>Nobody will be unable to use your code because it=
<i>doesn't</i> use exceptions. You don't see people shying away fr=
om stoi and so forth just because they don't report errors as exception=
s. People don't avoid iostreams just because they don't use excepti=
ons (by default). Users may not like it, or they may wrap it in a throwing =
interface if they're really anal about that sort of thing. But generall=
y speaking, they'll use what you provide based on whether it's good=
functionality, not based on your error reporting scheme.<br><br>And if `ex=
pected` were a standard library type, they'd be even more willing to us=
e code that uses it.<br><br>So I don't see a need for any kind of conve=
rgence between exceptions and `expected`.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">> APIs that use `expected` should not look like=
APIs that would throw
<br>> exceptions. And a user who calls the `expected` form does not gene=
rally
<br>> want to transform it into an exception.
<br>Well, it seems that you have a good experience with expected. What=20
<br>people do is out of the scope of the standard.<br></blockquote><div><br=
>No, it is very much a matter of the standard. They don't just stick th=
ings into the language/library and expect people to do whatever with them. =
Features are added because they are expected to make things easier for user=
s. So no, what people do with it is very much a part of why something shoul=
d be standardized.<br><br>And however much you may see `expected` as some m=
onadic functional whatever, to most people it is "a good way to handle=
errors without exceptions". Just as `await` is not "do notation&=
quot; or somesuch; it's a way to schedule the continuation of a functio=
n.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> I'm=
fine with `value` throwing; it fits with other similar types (optional,
<br>> etc). What I'm against is the idea that we should dynamically =
switch
<br>> between expected and exceptions, that they should be equated and e=
asily
<br>> inter-operable.
<br>Why?<br></blockquote><div><br>I explained this very carefully, but you =
ignored it. I explained how `exception_ptr` carries no useful semantic info=
rmation about the error, and therefore returning `expected<T, exception_=
ptr>` is substantially less useful to most users than returning `expecte=
d<T, some_error_type>`. I explained how many of the people who are in=
terested in `expected` are people who <i>cannot use exceptions</i>, and the=
refore cannot use `expected<T, exception_ptr>`, since they cannot ret=
hrow it.<br><br>So you should explain why a user would want a function to r=
eturn `expected<T, exception_ptr>`. Explain why a user would want tha=
t and what they would expect to do with it in the event of an error. Why do=
we need special interoperation functionality between expected and exceptio=
ns?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> If you h=
ave to annotate every propagation of an error with `await`, it's
<br>> not "transparent".
<br>It is better than adding a check :)
<br></blockquote><div><br>Considering the various machinery and compilation=
gymnastics needed to make `await expected` work, I wouldn't be too sur=
e about that. At the very least, you have yet to <i>prove</i> what the full=
consequences will be relative to doing it manually.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">> If you have to modify your return =
value, it's not
<br>> "transparent".
<br>I don't need to modify it. I want to return expected.
<br>> If you can't pass different kinds of error codes without
<br>> even more modifications to your return value (`expected<T, vari=
ant<E1, E2,
<br>> ...>>`), it's not "transparent".
<br>Hmm, I was expecting this ;-) =C2=A0Do you want to return expected<T=
,=20
<br>variant<E1, E2, ...>>?
<br>Do you want to return expected <T,E>? =C2=A0you can also. You cou=
ld even=20
<br>return expected <T,any>.<br></blockquote><div><br>Of course, the =
best way to encapsulate an error is by allocating memory. /s<br><br>Every a=
ttempt you produce to help make `expected` better at non-local error handli=
ng only validates the current design for exceptions <i>more</i>. When you h=
ave to invent new syntax and pervert the meaning of a keyword in the langua=
ge, that should be a sign that you're doing error handling wrong.<br><b=
r>`expected` should be for immediate handling of the error. If someone else=
is going to handle it, you should have thrown an exception instead of retu=
rning `expected`.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
> And if functions that use this syntax
<br>> can't also use futures or other forms of `await`, it's not=
"transparent".
<br>You can use futures, but I believe that you can not use await on them=
=20
<br>transparently. We need to know what this mean.
<br>
<br>>
<br>> Hijacking `await` machinery has consequences. And those consequenc=
es are
<br>> far from "transparent" to the user. I would personally m=
uch rather you just
<br>> use the right error mechanism. If you want local handling, call th=
e API
<br>> that returns `expected`. If you want non-local handling, call the =
API that
<br>> throws.
<br>I see that you don't want await on expected. Maybe you will change =
once=20
<br>every one is using it.<br></blockquote><div><br>Oh, I'm sure Bjarne=
Stroustrup is waiting with baited breath to add "use await with expec=
ted" and "favor expected over exceptions" to the core guidel=
ines. /s<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>> But please keep in mind Study Group 14. These are people who canno=
t use
<br>> exceptions. People who cannot have objects randomly allocating mem=
ory. But
<br>> they are also people who need a good alternative error handling me=
chanism,
<br>> one that can be added to standard library interfaces so that they =
can use
<br>> them in lieu of the exception versions.
<br>I don't see how anything I'm proposing couldn't be used by =
SG14.<br></blockquote><div><br>Every time you say that `expected<T, exce=
ption_ptr>` is useful, every time you think that there should be converg=
ence between exceptions and expected, you are talking about something that =
cannot be used by SG14.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">>
<br>> `expected` is exactly what they're looking for. If `value` thr=
ows, that's
<br>> fine; they can just avoid calling it. But they need to be able to =
have an
<br>> alternative error mechanism that can be standardized. You should p=
robably
<br>> get with those guys, because they could probably help `expected` g=
et pushed
<br>> forward. It's exactly the sort of thing they want.
<br>I know this.
<br>>
<br>> Oh, and one more thing. `expected` is, functionally speaking, a ki=
nd of
<br>> never-empty variant with a specialized interface. So I'm curio=
us as to
<br>> exactly how you solve the various issues that surrounded the more
<br>> generalized `variant` class. It's not clear from your current =
proposal how
<br>> you can provide the exception guarantees that it claims.
<br>Hmm, I was expecting that also ;-) But SG14 would not be concerned by=
=20
<br>the possible issue, isn't it?<br></blockquote><div><br>That's w=
hy I said "one more thing". That was a change of topic.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>> For example, on copy-assignment from another `expected`, you say t=
hat if
<br>> the copy constructor for the type in the source expected fails, &q=
uot;no
<br>> effect". How do you implement that if `T` or `E` is not nothr=
ow
<br>> copy/moveable? Do you double-buffer?
<br>>
<br>> I suggest you take a look at the current P0088 variant proposal an=
d
<br>> investigate the issues that prompted it to get an `invalid` state.=
Because
<br>> `expected` only has two types, and one of them is an error type, y=
ou could
<br>> probably impose more restrictive requirements on E that make it po=
ssible to
<br>> implement your guarantees. For example, you could require that E i=
s nothrow
<br>> moveable, which makes it possible to implement your guarantees wit=
hout
<br>> double-buffering.
<br>>
<br>Thanks for the suggestion.
<br>Maybe you understand now why expected was frozen during 1 year.<br></bl=
ockquote><div><br></div>If you were honestly waiting for variant's desi=
gn to be finished before updating your proposal, that was a bad idea on you=
r part. All the issues brought up in the variant discussions were applicabl=
e to=20
`expected`, so you shouldn't have been sitting on the sidelines. Becaus=
e the current possibly-invalid design we have arrived at is not reasonable =
for `expected`.<br><br>`expected`, despite being similar to a `variant`, is=
a different class with different needs. So its design should not have been=
dependent on the outcome of the various `variant` proposals.<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9413_103230049.1447358793071--
------=_Part_9412_1805406315.1447358793070--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 12 Nov 2015 15:35:03 -0500
Raw View
--001a11c36b2ab5cebf05245de0d2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :
>
>> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet
>> Escriba
>> wrote:
>>
>>> Hi,
>>>
>>> I would like to re-raise the expected discussion. Beside the conflictin=
g
>>> part "managing errors in a different way", that should be covered by a
>>> specific paper, I would like to open the discussion in order to have a
>>> better proposal for expected.
>>>
>>> There were some concerns about the exception throw when there is no
>>> value.
>>> I'm wondering if we can do as for basic_string, we can have an
>>> error_traits
>>> that define which exception is thrown and that can also do conversion
>>> from
>>> exception to errors.
>>>
>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>>
>>>
>>> we could have a specialization for error_code/error_condition that woul=
d
>>> throw a system_error.
>>>
>>> What do you think of this customization?
>>>
>>> Suggestion:
>>
>> Instead of a trait class, if except<T, E> would raise an exception, call=
:
>>
>> [[notreturn]] void std::rethrow(E&&e);
>>
> We have rethrow_exception. Are you talking of a new function?
>
>>
>> if E is one of std::exception_ptr, std::error_code then std::rethrow doe=
s
>> the obvious thing.
>>
> That is, ...
>
>> For a generic E std::rethrow performs an unqualified
>> call to adl_rethrow(e). The default would just throw e.
>>
>> It seems that adl calls are the preferred customization method with the
>> standard. The names are of course to be subjected to bikeshedding.
>>
>>
> I don't mind how we customize the behavior. However, it seems that there
> are some people that are against customizing the exception to throw.
> I would like to hear from those that would need to customize the behavior=
..
> What others think of customizing rethrow or rethrow_exception?
>
>
>
So, obviously, you are getting lots of different opinions from different
people.
For example, Nevin mentioned that he doesn't like basic_string + traits
because no one really uses the traits.
Other people want/expect that if E is an exception_ptr, it should rethrow
it, not throw bad_expected_access<exception_ptr>.
Some people want it to be consistent, always throw bad_expected_access.
Some people want to avoid exceptions.
Etc.
And this is how the committee works. Or fails to work, sometimes.
So you think "allow customization - that will make everyone happy". But
even that doesn't, because then those who want simplicity are not happy.
We need to look at each facet/opinion carefully. For example, in general I
agree with Nevin - basically the committee tends to over-customize when the
average user doesn't want/need it. But is that the case here? Instead of
saying "OK I won't do traits", maybe you should say "here's how expected<>
is different than basic_string...." ie even if we tend to over-customize,
maybe this is a case where customization is useful. Or maybe not.
So how to decide that?
I think we first look at those wanting to avoid exceptions. So they will
use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or
similar.
OK. Did they avoid exceptions? Well, almost, but not really. If they call
ex.value() without checking, they may still get a bad_expected_access<int>
exception. But note - only if they call it. And I suspect it would be
easy for an implementation to just make that UB when/if the developer shuts
off exceptions in their compiler.
So, 1. we don't need to define expected.value() to have undefined behaviour
- it WILL throw. The only question is what it throws. So let's not talk
about IF it throws. Yes it does.
Now, what about expected<T, exception_ptr>. I think I understand Nicol's
logic of "if I wanted to use exceptions, I wouldn't have used expected".
HOWEVER...
Let's look at FileSystem's API. I think it sucks - in the fact that is
double the API, for exception vs non-exception modes. I'd love to replace
it with a single API. Can expected<> solve FileSystem's API?
0. You could argue that it shouldn't be solved. ie there are more library
callers than library writers, so don't optimize the API for the library
writers. I don't think I am. I hate the API as a USER. I'd prefer a
single API to make the API easier to understand - for the caller.
So how could expected<> help FileSystem? I think it would work best if
expected threw a *FileSystem* exception on bad access. NOT
bad_expected_access. If it threw a FileSystem exception, I think you would
have both APIs in one. (I could be wrong here, it's been years since I
looked at FileSystem closely.)
Do people think that the above is a bad way to make an API? Or should
FileSystem continue to have its dual API? Are there other examples?
If FileSystem is a good example, I think the leads towards _some_ form of
customization.
As for how to customize:
External: "external" customization, such as expected could call the free
function expected_customization_throw_something_given_this_error(E e). (Or
look up an external traits class.) I don't think this works. Too often E
will just be int. And FileSystem's ints aren't the same as Windows HRESULT
ints, etc. We could always wrap the ints, should we need to?
Magic: expected could just "do the right thing". ie if E is exception_ptr,
then rethrow it. if E is derived from exception, throw it. otherwise
throw bad_expected_access<E>.
Always Throw E. Simple. But then you get a bunch of ints being thrown. I
think this is a no-go option.
Always Throw bad_expected_access<E>. Simple. Possibly unexpected. And
doesn't "unify" APIs like FileSystem.
Templatized: customize via a traits class *passed in* (which could default
to magic or whatever). APIs like FileSystem can turns int errors into
exceptions *at the point when expected.value() is called*. (The "wrap E
with as_error/as_exception" idea would also go here under "Templatized".)
NOTE: for FileSystem, the Magic option means, to unify its APIs, it would
need to use exception_ptr (or maybe some E derived from std::exception), so
that the "right" FileSystem exception is thrown. This is bad for users
that want to use FileSystem but avoid exceptions.
----
Conclusions?
1. If we find we need customization, I don't think it can be external (too
many int errors), it needs to be part of the template.
2. I don't think I like exception_ptr. It doesn't help an API like
FileSystem that is trying to avoid exceptions. I'd prefer a trait-based
customization, or throw E when E is derived from std::exception - because
you can use std::exception without using exceptions. Can you give me more
uses for expected<T, exception_ptr>?
3. Can someone give more examples (like FileSystem) where customization,
such as "error code turns into specific exception", is useful?
3.b is FileSystem a worthy example?
Tony
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c36b2ab5cebf05245de0d2
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 Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <span dir=3D"=
ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><span class=3D"">Le 12/11/2015 16:26, Giovanni Piero D=
eretta a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet Escriba=
<br>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the conflicting<br=
>
part "managing errors in a different way", that should be covered=
by a<br>
specific paper, I would like to open the discussion in order to have a<br>
better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is no value.<=
br>
I'm wondering if we can do as for basic_string, we can have an error_tr=
aits<br>
that define which exception is thrown and that can also do conversion from<=
br>
exception to errors.<br>
<br>
basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error=
>><br>
<br>
we could have a specialization for error_code/error_condition that would<br=
>
throw a system_error.<br>
<br>
What do you think of this customization?<br>
<br>
</blockquote>
Suggestion:<br>
<br>
Instead of a trait class, if except<T, E> would raise an exception, c=
all:<br>
<br>
[[notreturn]] void std::rethrow(E&&e);<br>
</blockquote></span>
We have rethrow_exception. Are you talking of a new function?<span class=3D=
""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
if E is one of std::exception_ptr, std::error_code then std::rethrow does<b=
r>
the obvious thing.<br>
</blockquote></span>
That is, ...<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
For a generic E std::rethrow performs an unqualified<br>
call to adl_rethrow(e). The default would just throw e.<br>
<br>
It seems that adl calls are the preferred customization method with the<br>
standard. The names are of course to be subjected to bikeshedding.<br>
<br>
</blockquote>
<br></span>
I don't mind how we customize the behavior. However, it seems that ther=
e are some people that are against customizing the exception to throw.<br>
I would like to hear from those that would need to customize the behavior.<=
br>
What others think of customizing rethrow or rethrow_exception?<span class=
=3D""><font color=3D"#888888"><br>
<br>
<br></font></span></blockquote><div><br></div></div>So, obviously, you are =
getting lots of different opinions from different people.<br></div><div cla=
ss=3D"gmail_extra">For example, Nevin mentioned that he doesn't like ba=
sic_string + traits because no one really uses the traits.<br></div><div cl=
ass=3D"gmail_extra">Other people want/expect that if E is an exception_ptr,=
it should rethrow it, not throw bad_expected_access<exception_ptr>.<=
br></div><div class=3D"gmail_extra">Some people want it to be consistent, a=
lways throw bad_expected_access.<br></div><div class=3D"gmail_extra">Some p=
eople want to avoid exceptions.<br>Etc.<br><br></div><div class=3D"gmail_ex=
tra">And this is how the committee works.=C2=A0 Or fails to work, sometimes=
..<br><br></div><div class=3D"gmail_extra">So you think "allow customiz=
ation - that will make everyone happy".=C2=A0 But even that doesn'=
t, because then those who want simplicity are not happy.<br><br></div><div =
class=3D"gmail_extra">We need to look at each facet/opinion carefully.=C2=
=A0 For example, in general I agree with Nevin - basically the committee te=
nds to over-customize when the average user doesn't want/need it.=C2=A0=
But is that the case here?=C2=A0 Instead of saying "OK I won't do=
traits", maybe you should say "here's how expected<> i=
s different than basic_string...."=C2=A0 ie even if we tend to over-cu=
stomize, maybe this is a case where customization is useful. Or maybe not.<=
br><br></div><div class=3D"gmail_extra">So how to decide that?<br><br></div=
><div class=3D"gmail_extra">I think we first look at those wanting to avoid=
exceptions.=C2=A0 So they will use expected<T, MyErrorCode> probably=
equivalent to expected<T, int>. Or similar.<br></div><div class=3D"g=
mail_extra">OK. Did they avoid exceptions? Well, almost, but not really.=C2=
=A0 If they call ex.value() without checking, they may still get a bad_expe=
cted_access<int> exception.=C2=A0 But note - only if they call it.=C2=
=A0 And I suspect it would be easy for an implementation to just make that =
UB when/if the developer shuts off exceptions in their compiler.<br><br></d=
iv><div class=3D"gmail_extra">So, 1. we don't need to define expected.v=
alue() to have undefined behaviour - it WILL throw.=C2=A0 The only question=
is what it throws.=C2=A0 So let's not talk about IF it throws. Yes it =
does.<br><br></div><div class=3D"gmail_extra">Now, what about expected<T=
, exception_ptr>.=C2=A0 I think I understand Nicol's logic of "=
if I wanted to use exceptions, I wouldn't have used expected".<br>=
</div><div class=3D"gmail_extra">HOWEVER...<br><br></div><div class=3D"gmai=
l_extra">Let's look at FileSystem's API.=C2=A0 I think it sucks - i=
n the fact that is double the API, for exception vs non-exception modes.=C2=
=A0 I'd love to replace it with a single API.=C2=A0 Can expected<>=
; solve FileSystem's API?<br><br></div><div class=3D"gmail_extra">0. Yo=
u could argue that it shouldn't be solved.=C2=A0 ie there are more libr=
ary callers than library writers, so don't optimize the API for the lib=
rary writers.=C2=A0 I don't think I am.=C2=A0 I hate the API as a USER.=
=C2=A0 I'd prefer a single API to make the API easier to understand - f=
or the caller.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">So how could expected<> help FileSystem?=C2=A0 I think i=
t would work best if expected threw a *FileSystem* exception on bad access.=
NOT bad_expected_access.=C2=A0 If it threw a FileSystem exception, I think=
you would have both APIs in one.=C2=A0 (I could be wrong here, it's be=
en years since I looked at FileSystem closely.)<br><br></div><div class=3D"=
gmail_extra">Do people think that the above is a bad way to make an API?=C2=
=A0 Or should FileSystem continue to have its dual API?=C2=A0 Are there oth=
er examples?<br><br></div><div class=3D"gmail_extra">If FileSystem is a goo=
d example, I think the leads towards _some_ form of customization.<br><br><=
/div><div class=3D"gmail_extra">As for how to customize:<br><br></div><div =
class=3D"gmail_extra">External: "external" customization, such as=
expected could call the free function expected_customization_throw_somethi=
ng_given_this_error(E e).=C2=A0 (Or look up an external traits class.) I do=
n't think this works.=C2=A0 Too often E will just be int.=C2=A0 And Fil=
eSystem's ints aren't the same as Windows HRESULT ints, etc.=C2=A0 =
We could always wrap the ints, should we need to?<br><br></div><div class=
=3D"gmail_extra">Magic: expected could just "do the right thing".=
=C2=A0 ie if E is exception_ptr, then rethrow it.=C2=A0 if E is derived fro=
m exception, throw it.=C2=A0 otherwise throw bad_expected_access<E>.<=
br><br></div><div class=3D"gmail_extra">Always Throw E.=C2=A0 Simple.=C2=A0=
But then you get a bunch of ints being thrown.=C2=A0 I think this is a no-=
go option.<br><br></div><div class=3D"gmail_extra">Always Throw bad_expecte=
d_access<E>.=C2=A0 Simple.=C2=A0 Possibly unexpected.=C2=A0 And doesn=
't "unify" APIs like FileSystem.<br><br></div><div class=3D"g=
mail_extra">Templatized: customize via a traits class *passed in* (which co=
uld default to magic or whatever).=C2=A0 APIs like FileSystem can turns int=
errors into exceptions *at the point when expected.value() is called*.=C2=
=A0 (The "wrap E with as_error/as_exception" idea would also go h=
ere under "Templatized".)<br></div><div class=3D"gmail_extra"><br=
><br>NOTE: for FileSystem, the Magic option means, to unify its APIs, it wo=
uld need to=20
use exception_ptr (or maybe some E derived from std::exception), so that th=
e "right" FileSystem exception is thrown.=C2=A0=20
This is bad for users that want to use FileSystem but avoid exceptions.<br>=
<br>----<br><br></div><div class=3D"gmail_extra">Conclusions?<br></div><div=
class=3D"gmail_extra">1. If we find we need customization, I don't thi=
nk it can be external (too many int errors), it needs to be part of the tem=
plate.<br><br></div><div class=3D"gmail_extra">2. I don't think I like =
exception_ptr.=C2=A0 It doesn't help an API like FileSystem that is try=
ing to avoid exceptions.=C2=A0 I'd prefer a trait-based customization, =
or throw E when E is derived from std::exception - because you can use std:=
:exception without using exceptions. Can you give me more uses for expected=
<T, exception_ptr>?<br></div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra">3. Can someone give more examples (like FileSystem)=
where customization, such as "error code turns into specific exceptio=
n", is useful?<br></div><div class=3D"gmail_extra">3.b is FileSystem a=
worthy example?<br><br></div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c36b2ab5cebf05245de0d2--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 12 Nov 2015 23:15:46 +0100
Raw View
Le 12/11/2015 21:35, Tony V E a =C3=A9crit :
> On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :
>>
>>> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet
>>> Escriba
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to re-raise the expected discussion. Beside the conflicti=
ng
>>>> part "managing errors in a different way", that should be covered by a
>>>> specific paper, I would like to open the discussion in order to have a
>>>> better proposal for expected.
>>>>
>>>> There were some concerns about the exception throw when there is no
>>>> value.
>>>> I'm wondering if we can do as for basic_string, we can have an
>>>> error_traits
>>>> that define which exception is thrown and that can also do conversion
>>>> from
>>>> exception to errors.
>>>>
>>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>=
>
>>>>
>>>> we could have a specialization for error_code/error_condition that wou=
ld
>>>> throw a system_error.
>>>>
>>>> What do you think of this customization?
>>>>
>>>> Suggestion:
>>> Instead of a trait class, if except<T, E> would raise an exception, cal=
l:
>>>
>>> [[notreturn]] void std::rethrow(E&&e);
>>>
>> We have rethrow_exception. Are you talking of a new function?
>>
>>> if E is one of std::exception_ptr, std::error_code then std::rethrow do=
es
>>> the obvious thing.
>>>
>> That is, ...
>>
>>> For a generic E std::rethrow performs an unqualified
>>> call to adl_rethrow(e). The default would just throw e.
>>>
>>> It seems that adl calls are the preferred customization method with the
>>> standard. The names are of course to be subjected to bikeshedding.
>>>
>>>
>> I don't mind how we customize the behavior. However, it seems that there
>> are some people that are against customizing the exception to throw.
>> I would like to hear from those that would need to customize the behavio=
r.
>> What others think of customizing rethrow or rethrow_exception?
>>
>>
>>
> So, obviously, you are getting lots of different opinions from different
> people.
> For example, Nevin mentioned that he doesn't like basic_string + traits
> because no one really uses the traits.
> Other people want/expect that if E is an exception_ptr, it should rethrow
> it, not throw bad_expected_access<exception_ptr>.
> Some people want it to be consistent, always throw bad_expected_access.
> Some people want to avoid exceptions.
> Etc.
>
> And this is how the committee works. Or fails to work, sometimes.
>
> So you think "allow customization - that will make everyone happy". But
> even that doesn't, because then those who want simplicity are not happy.
>
> We need to look at each facet/opinion carefully. For example, in general=
I
> agree with Nevin - basically the committee tends to over-customize when t=
he
> average user doesn't want/need it. But is that the case here? Instead o=
f
> saying "OK I won't do traits", maybe you should say "here's how expected<=
>
> is different than basic_string...." ie even if we tend to over-customize=
,
> maybe this is a case where customization is useful. Or maybe not.
>
> So how to decide that?
>
> I think we first look at those wanting to avoid exceptions. So they will
> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or
> similar.
> OK. Did they avoid exceptions? Well, almost, but not really. If they cal=
l
> ex.value() without checking, they may still get a bad_expected_access<int=
>
> exception. But note - only if they call it. And I suspect it would be
> easy for an implementation to just make that UB when/if the developer shu=
ts
> off exceptions in their compiler.
>
> So, 1. we don't need to define expected.value() to have undefined behavio=
ur
> - it WILL throw. The only question is what it throws. So let's not talk
> about IF it throws. Yes it does.
>
> Now, what about expected<T, exception_ptr>. I think I understand Nicol's
> logic of "if I wanted to use exceptions, I wouldn't have used expected".
> HOWEVER...
I want expected<T, exception_ptr>as storage of future<T>. I believe that=20
the future::then continuation should take an expected<T, exception_ptr>=20
as parameter, not a future<T>.
>
> Let's look at FileSystem's API. I think it sucks - in the fact that is
> double the API, for exception vs non-exception modes. I'd love to replac=
e
> it with a single API. Can expected<> solve FileSystem's API?
>
> 0. You could argue that it shouldn't be solved. ie there are more librar=
y
> callers than library writers, so don't optimize the API for the library
> writers. I don't think I am. I hate the API as a USER. I'd prefer a
> single API to make the API easier to understand - for the caller.
>
> So how could expected<> help FileSystem? I think it would work best if
> expected threw a *FileSystem* exception on bad access. NOT
> bad_expected_access. If it threw a FileSystem exception, I think you wou=
ld
> have both APIs in one. (I could be wrong here, it's been years since I
> looked at FileSystem closely.)
>
> Do people think that the above is a bad way to make an API? Or should
> FileSystem continue to have its dual API? Are there other examples?
>
> If FileSystem is a good example, I think the leads towards _some_ form of
> customization.
>
> As for how to customize:
>
> External: "external" customization, such as expected could call the free
> function expected_customization_throw_something_given_this_error(E e). (=
Or
> look up an external traits class.) I don't think this works. Too often E
> will just be int. And FileSystem's ints aren't the same as Windows HRESU=
LT
> ints, etc. We could always wrap the ints, should we need to?
>
> Magic: expected could just "do the right thing". ie if E is exception_pt=
r,
> then rethrow it. if E is derived from exception, throw it. otherwise
> throw bad_expected_access<E>.
>
> Always Throw E. Simple. But then you get a bunch of ints being thrown. =
I
> think this is a no-go option.
>
> Always Throw bad_expected_access<E>. Simple. Possibly unexpected. And
> doesn't "unify" APIs like FileSystem.
>
> Templatized: customize via a traits class *passed in* (which could defaul=
t
> to magic or whatever). APIs like FileSystem can turns int errors into
> exceptions *at the point when expected.value() is called*. (The "wrap E
> with as_error/as_exception" idea would also go here under "Templatized".)
>
>
> NOTE: for FileSystem, the Magic option means, to unify its APIs, it would
> need to use exception_ptr (or maybe some E derived from std::exception), =
so
> that the "right" FileSystem exception is thrown. This is bad for users
> that want to use FileSystem but avoid exceptions.
>
> ----
>
> Conclusions?
> 1. If we find we need customization, I don't think it can be external (to=
o
> many int errors), it needs to be part of the template.
>
> 2. I don't think I like exception_ptr. It doesn't help an API like
> FileSystem that is trying to avoid exceptions. I'd prefer a trait-based
> customization, or throw E when E is derived from std::exception - because
> you can use std::exception without using exceptions. Can you give me more
> uses for expected<T, exception_ptr>?
>
> 3. Can someone give more examples (like FileSystem) where customization,
> such as "error code turns into specific exception", is useful?
> 3.b is FileSystem a worthy example?
>
>
>
Thanks Tony for the summary.
I would like to hear more people. Maybe it is time to move to the LEWG ML.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Thu, 12 Nov 2015 23:25:09 +0100
Raw View
On 11/12/2015 09:35 PM, Tony V E wrote:
> Do people think that the above is a bad way to make an API? Or should
> FileSystem continue to have its dual API? Are there other examples?
Another example is the Networking TS proposal, which has the same
duplicated API as Filesystem TS for its synchronous operations.
Furthermore, the asynchronous operations in Networking TS returns
the "return value" as two input arguments to a completion handler
(callback) like this:
socket.async_receive(buffer, [] (error_code, size_t) {});
Using expected<> instead of two conceptually mutually exclusive
arguments seems like a much cleaner solution.
As for customization, I have only had the need for system_error
to wrap error_code so far when working with the abovementioned APIs,
although I can see the usefulness of throwing exceptions that inherit
from system_error in some cases.
Regarding bad_expected_access, this is a logic error so I do not really
see the point in being about to customize it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Thu, 12 Nov 2015 16:01:37 -0800 (PST)
Raw View
------=_Part_961_1047609985.1447372897907
Content-Type: multipart/alternative;
boundary="----=_Part_962_85201189.1447372897908"
------=_Part_962_85201189.1447372897908
Content-Type: text/plain; charset=UTF-8
On Thursday, 12 November 2015 22:25:12 UTC, Bjorn Reese wrote:
>
> On 11/12/2015 09:35 PM, Tony V E wrote:
>
> > Do people think that the above is a bad way to make an API? Or should
> > FileSystem continue to have its dual API? Are there other examples?
>
> Another example is the Networking TS proposal, which has the same
> duplicated API as Filesystem TS for its synchronous operations.
>
> Furthermore, the asynchronous operations in Networking TS returns
> the "return value" as two input arguments to a completion handler
> (callback) like this:
>
> socket.async_receive(buffer, [] (error_code, size_t) {});
>
> Using expected<> instead of two conceptually mutually exclusive
> arguments seems like a much cleaner solution.
>
I would very much hope for expected<> to have built-in support for
error_code, indeed for the system_error mechanism in general. This would
also appear to solve the int problem; any API that returns raw ints (as
opposed to values of an enumeration that could be adapted to system_error)
is probably returning a general platform error code, so at least on POSIX
can be static_cast to std::errc. This would also allow combining
expected<>s from different domains - one can combine an expected<T,
std::future_errc> with an expected<T, std::io_errc> to get an expected<T,
std::error_code>.
> As for customization, I have only had the need for system_error
> to wrap error_code so far when working with the abovementioned APIs,
> although I can see the usefulness of throwing exceptions that inherit
> from system_error in some cases.
>
Has anyone considered adding a virtual [[noreturn]] throw_error() to
std::error_category? The base case could throw std::system_error, but
std::iostream_category would throw std::ios_base::failure, and so on.
> Regarding bad_expected_access, this is a logic error so I do not really
> see the point in being about to customize it.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_962_85201189.1447372897908
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, 12 November 2015 22:25:12 UTC, Bjorn Reese w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On 11/12/2015 09:35 PM, T=
ony V E wrote:
<br>
<br>> Do people think that the above is a bad way to make an API? =C2=A0=
Or should
<br>> FileSystem continue to have its dual API? =C2=A0Are there other ex=
amples?
<br>
<br>Another example is the Networking TS proposal, which has the same
<br>duplicated API as Filesystem TS for its synchronous operations.
<br>
<br>Furthermore, the asynchronous operations in Networking TS returns
<br>the "return value" as two input arguments to a completion han=
dler
<br>(callback) like this:
<br>
<br>=C2=A0 =C2=A0socket.async_receive(buffer, [] (error_code, size_t) {});
<br>
<br>Using expected<> instead of two conceptually mutually exclusive
<br>arguments seems like a much cleaner solution.
<br></blockquote><div><br></div><div>I would very much hope for expected<=
;> to have built-in support for error_code, indeed for the system_error =
mechanism in general. This would also appear to solve the int problem; any =
API that returns raw ints (as opposed to values of an enumeration that coul=
d be adapted to system_error) is probably returning a general platform erro=
r code, so at least on POSIX can be static_cast to std::errc. This would al=
so allow combining expected<>s from different domains - one can combi=
ne an expected<T, std::future_errc> with an expected<T, std::io_er=
rc> to get an expected<T, std::error_code>.</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">As for customization, I have o=
nly had the need for system_error
<br>to wrap error_code so far when working with the abovementioned APIs,
<br>although I can see the usefulness of throwing exceptions that inherit
<br>from system_error in some cases.
<br></blockquote><div><br></div><div>Has anyone considered adding a virtual=
[[noreturn]] throw_error() to std::error_category? The base case could thr=
ow std::system_error, but std::iostream_category would throw std::ios_base:=
:failure, and so on.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">Regarding bad_expected_access, this is a logic error so I do n=
ot really
<br>see the point in being about to customize it.
<br></blockquote><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_962_85201189.1447372897908--
------=_Part_961_1047609985.1447372897907--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 16:28:42 -0800 (PST)
Raw View
------=_Part_1290_460768859.1447374522580
Content-Type: multipart/alternative;
boundary="----=_Part_1291_893178045.1447374522581"
------=_Part_1291_893178045.1447374522581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 3:35:06 PM UTC-5, Tony V E wrote:
>
> On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <
> vicent...@wanadoo.fr> wrote:
>
>> Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :
>>
>>> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet=20
>>> Escriba
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to re-raise the expected discussion. Beside the conflicti=
ng
>>>> part "managing errors in a different way", that should be covered by a
>>>> specific paper, I would like to open the discussion in order to have a
>>>> better proposal for expected.
>>>>
>>>> There were some concerns about the exception throw when there is no=20
>>>> value.
>>>> I'm wondering if we can do as for basic_string, we can have an=20
>>>> error_traits
>>>> that define which exception is thrown and that can also do conversion=
=20
>>>> from
>>>> exception to errors.
>>>>
>>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>=
>
>>>>
>>>> we could have a specialization for error_code/error_condition that wou=
ld
>>>> throw a system_error.
>>>>
>>>> What do you think of this customization?
>>>>
>>>> Suggestion:
>>>
>>> Instead of a trait class, if except<T, E> would raise an exception, cal=
l:
>>>
>>> [[notreturn]] void std::rethrow(E&&e);
>>>
>> We have rethrow_exception. Are you talking of a new function?
>>
>>>
>>> if E is one of std::exception_ptr, std::error_code then std::rethrow do=
es
>>> the obvious thing.
>>>
>> That is, ...
>>
>>> For a generic E std::rethrow performs an unqualified
>>> call to adl_rethrow(e). The default would just throw e.
>>>
>>> It seems that adl calls are the preferred customization method with the
>>> standard. The names are of course to be subjected to bikeshedding.
>>>
>>>
>> I don't mind how we customize the behavior. However, it seems that there=
=20
>> are some people that are against customizing the exception to throw.
>> I would like to hear from those that would need to customize the behavio=
r.
>> What others think of customizing rethrow or rethrow_exception?
>>
>>
>>
> So, obviously, you are getting lots of different opinions from different=
=20
> people.
> For example, Nevin mentioned that he doesn't like basic_string + traits=
=20
> because no one really uses the traits.
> Other people want/expect that if E is an exception_ptr, it should rethrow=
=20
> it, not throw bad_expected_access<exception_ptr>.
>
Actually, outside of the OP, I think you're the first one who's come out in=
=20
favor of the position that `expected<T, exception_ptr>` should rethrow the=
=20
exception_ptr in `value()`. Everyone else has either said no or expressed a=
=20
desire for a different customization mechanism.
=20
> Some people want it to be consistent, always throw bad_expected_access.
> Some people want to avoid exceptions.
> Etc.
>
> And this is how the committee works. Or fails to work, sometimes.
>
> So you think "allow customization - that will make everyone happy". But=
=20
> even that doesn't, because then those who want simplicity are not happy.
>
> We need to look at each facet/opinion carefully. For example, in general=
=20
> I agree with Nevin - basically the committee tends to over-customize when=
=20
> the average user doesn't want/need it. But is that the case here? Inste=
ad=20
> of saying "OK I won't do traits", maybe you should say "here's how=20
> expected<> is different than basic_string...." ie even if we tend to=20
> over-customize, maybe this is a case where customization is useful. Or=20
> maybe not.
>
> So how to decide that?
>
> I think we first look at those wanting to avoid exceptions. So they will=
=20
> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or=
=20
> similar.
> OK. Did they avoid exceptions? Well, almost, but not really. If they cal=
l=20
> ex.value() without checking, they may still get a bad_expected_access<int=
>=20
> exception. But note - only if they call it. And I suspect it would be=
=20
> easy for an implementation to just make that UB when/if the developer shu=
ts=20
> off exceptions in their compiler.
>
> So, 1. we don't need to define expected.value() to have undefined=20
> behaviour - it WILL throw. The only question is what it throws. So let'=
s=20
> not talk about IF it throws. Yes it does.
>
> Now, what about expected<T, exception_ptr>. I think I understand Nicol's=
=20
> logic of "if I wanted to use exceptions, I wouldn't have used expected".
> HOWEVER...
>
> Let's look at FileSystem's API. I think it sucks - in the fact that is=
=20
> double the API, for exception vs non-exception modes. I'd love to replac=
e=20
> it with a single API. Can expected<> solve FileSystem's API?
>
> 0. You could argue that it shouldn't be solved. ie there are more librar=
y=20
> callers than library writers, so don't optimize the API for the library=
=20
> writers. I don't think I am. I hate the API as a USER. I'd prefer a=20
> single API to make the API easier to understand - for the caller.
>
> So how could expected<> help FileSystem? I think it would work best if=
=20
> expected threw a *FileSystem* exception on bad access. NOT=20
> bad_expected_access. If it threw a FileSystem exception, I think you wou=
ld=20
> have both APIs in one. (I could be wrong here, it's been years since I=
=20
> looked at FileSystem closely.)
>
> Do people think that the above is a bad way to make an API? Or should=20
> FileSystem continue to have its dual API? Are there other examples?
>
Here's the problem. Let's say I have this code, using the FileSystem TS:
void func(const fs::path &p)
{
...
error_code ec;
auto fsize =3D fs::file_size(p, &ec);
if(ec)
{
if(ec =3D=3D /*file not found*/) { std::cout << p << " does not exist.\=
n"; }
if(ec =3D=3D /*not a file*/) { std::cout << p << " is not a file.\n"; }
return;
}
//Use the size.
}
It's verbose, but fairly simple to deal with. If there's an error, I print=
=20
out a message based on that error.
Now, let's do it the expected<T, exception_ptr> way:
void func(const fs::path &p)
{
...
expected<size_t, exception_ptr> fsize =3D fs::file_size(p);
try
{
//Use the size
}
catch(std::filesystem_error &e)
{
if(e.code() =3D=3D /*file not found*/) { std::cout << e.path1() << " do=
es=20
not exist.\n"; }
if(e.code() =3D=3D /*not a file*/) { std::cout << e.path1() << " is not=
a=20
file.\n"; }
return;
}
}
Let's count the ways that this is bad:
1) I get redundant information. Because I'm in the function that called=20
`file_size`, I probably already know what path I passed. But the exception=
=20
dutifully passes it back to me.
2) I get an unneeded memory allocation. Not only did we allocate an=20
exception object, but we allocated the `path` that goes into it. When all I=
=20
really needed was the `error_code`. For codebases that need control over=20
allocations, this is a non-starter; the error code method was superior.
3) If I cannot use exceptions, this API is binary to me. I can know that an=
=20
error happened, but there's no way to introspect an `exception_ptr` to find=
=20
out why the error happened. So without throwing, you can't reproduce the=20
code.
The only people who would use this version of FileSystem are people who=20
would have just used the throwing version of FileSystem straight up. So=20
what's the point of using expected like this?
This is why `expected<T, exception_ptr>` is not a useful construct in=20
general. It can be useful in specific cases, but not as a general way of=20
passing back errors that users have to actually handle.
If you want a general mechanism that allows the calling code to decide=20
whether they want local or non-local error handling, having two separate=20
functions is really the best way to do it. You don't hamper the local=20
handling version with information and overhead they don't need, and you=20
don't hamper the non-local version with objects they don't need (like=20
`expected`).
The only problem I have with FileSystem is that it returns the error by=20
parameter instead of by `expected<T, error_code>`. I would still want to=20
have duplicate APIs even with `expected`.
No single error mechanism will be all things to all people. And trying to=
=20
make one will be naturally biased towards one side or the other.
Right now in the C++ world, we are divided. On the one hand, we have many=
=20
people who successfully use exceptions. On the other, we have people using=
=20
various ad-hoc error codes. We should not treat `expected` as a way to=20
merge these two worlds. Instead, we should treat `expected` as the proper=
=20
way to implement error code style-handling.
We need APIs to support both.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1291_893178045.1447374522581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 3:35:06 PM UTC-5, Tony V E wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <span =
dir=3D"ltr"><<a target=3D"_blank" rel=3D"nofollow">vicent...@wanadoo.fr<=
/a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<span>Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet Escriba=
<br>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
I would like to re-raise the expected discussion. Beside the conflicting<br=
>
part "managing errors in a different way", that should be covered=
by a<br>
specific paper, I would like to open the discussion in order to have a<br>
better proposal for expected.<br>
<br>
There were some concerns about the exception throw when there is no value.<=
br>
I'm wondering if we can do as for basic_string, we can have an error_tr=
aits<br>
that define which exception is thrown and that can also do conversion from<=
br>
exception to errors.<br>
<br>
basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error=
>><br>
<br>
we could have a specialization for error_code/error_condition that would<br=
>
throw a system_error.<br>
<br>
What do you think of this customization?<br>
<br>
</blockquote>
Suggestion:<br>
<br>
Instead of a trait class, if except<T, E> would raise an exception, c=
all:<br>
<br>
[[notreturn]] void std::rethrow(E&&e);<br>
</blockquote></span>
We have rethrow_exception. Are you talking of a new function?<span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
if E is one of std::exception_ptr, std::error_code then std::rethrow does<b=
r>
the obvious thing.<br>
</blockquote></span>
That is, ...<span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
For a generic E std::rethrow performs an unqualified<br>
call to adl_rethrow(e). The default would just throw e.<br>
<br>
It seems that adl calls are the preferred customization method with the<br>
standard. The names are of course to be subjected to bikeshedding.<br>
<br>
</blockquote>
<br></span>
I don't mind how we customize the behavior. However, it seems that ther=
e
are some people that are against customizing the exception to throw.<br>
I would like to hear from those that would need to customize the behavior.<=
br>
What others think of customizing rethrow or rethrow_exception?<span><font c=
olor=3D"#888888"><br>
<br>
<br></font></span></blockquote><div><br></div></div>So, obviously, you are =
getting lots of different opinions from different people.<br></div><div>For=
example, Nevin mentioned that he doesn't like basic_string + traits be=
cause no one really uses the traits.<br></div><div>Other people want/expect=
that if E is an exception_ptr, it should rethrow it, not throw bad_expecte=
d_access<exception_<wbr>ptr>.<br></div></div></blockquote><div><br>Ac=
tually,
outside of the OP, I think you're the first one who's come out in =
favor
of the position that `expected<T, exception_ptr>` should rethrow=20
the exception_ptr in `value()`. Everyone else has either said no or=20
expressed a desire for a different customization mechanism.<br>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Some peo=
ple want it to be consistent, always throw bad_expected_access.<br></div><d=
iv>Some people want to avoid exceptions.<br>Etc.<br><br></div><div>And this=
is how the committee works.=C2=A0 Or fails to work, sometimes.<br><br></di=
v><div>So
you think "allow customization - that will make everyone happy".=
=C2=A0 But=20
even that doesn't, because then those who want simplicity are not happy=
..<br><br></div><div>We
need to look at each facet/opinion carefully.=C2=A0 For example, in genera=
l I
agree with Nevin - basically the committee tends to over-customize when
the average user doesn't want/need it.=C2=A0 But is that the case here=
?=C2=A0=20
Instead of saying "OK I won't do traits", maybe you should sa=
y "here's=20
how expected<> is different than basic_string...."=C2=A0 ie even=
if we=20
tend to over-customize, maybe this is a case where customization is=20
useful. Or maybe not.<br><br></div><div>So how to decide that?<br><br></div=
><div>I
think we first look at those wanting to avoid exceptions.=C2=A0 So they wi=
ll
use expected<T, MyErrorCode> probably equivalent to=20
expected<T, int>. Or similar.<br></div><div>OK. Did they avoid=20
exceptions? Well, almost, but not really.=C2=A0 If they call ex.value()=20
without checking, they may still get a bad_expected_access<int>=20
exception.=C2=A0 But note - only if they call it.=C2=A0 And I suspect it wo=
uld be=20
easy for an implementation to just make that UB when/if the developer=20
shuts off exceptions in their compiler.<br><br></div><div>So, 1. we=20
don't need to define expected.value() to have undefined behaviour - it=
=20
WILL throw.=C2=A0 The only question is what it throws.=C2=A0 So let's n=
ot talk=20
about IF it throws. Yes it does.<br><br></div><div>Now, what about=20
expected<T, exception_ptr>.=C2=A0 I think I understand Nicol's lo=
gic of
"if I wanted to use exceptions, I wouldn't have used expected&quo=
t;.<br></div><div>HOWEVER...<br><br></div><div>Let's
look at FileSystem's API.=C2=A0 I think it sucks - in the fact that is=
=20
double the API, for exception vs non-exception modes.=C2=A0 I'd love to=
=20
replace it with a single API.=C2=A0 Can expected<> solve FileSystem&#=
39;s=20
API?<br><br></div><div>0. You could argue that it shouldn't be solved.=
=C2=A0=20
ie there are more library callers than library writers, so don't=20
optimize the API for the library writers.=C2=A0 I don't think I am.=C2=
=A0 I hate=20
the API as a USER.=C2=A0 I'd prefer a single API to make the API easier=
to=20
understand - for the caller.<br></div><div><br></div><div>So how could=20
expected<> help FileSystem?=C2=A0 I think it would work best if=20
expected threw a *FileSystem* exception on bad access. NOT=20
bad_expected_access.=C2=A0 If it threw a FileSystem exception, I think you=
=20
would have both APIs in one.=C2=A0 (I could be wrong here, it's been ye=
ars=20
since I looked at FileSystem closely.)<br><br></div><div>Do people think
that the above is a bad way to make an API?=C2=A0 Or should FileSystem=20
continue to have its dual API?=C2=A0 Are there other examples?<br></div></d=
iv></blockquote><br>Here's the problem. Let's say I have this code,=
using the FileSystem TS:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fs<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">path </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 error_code ec</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> fsize </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
fs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">file_size</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">ec</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">ec</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">ec </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">/*file not found*/</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> p </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">" does not exist.\n"</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">ec </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/*not=
a file*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> p </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><<</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">" is not a file.\n"</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Use the s=
ize.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></di=
v></code></div><br>It's verbose, but fairly simple to deal with. If the=
re's an error, I print out a message based on that error.<br><br>Now, l=
et's do it the expected<T, exception_ptr> way:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> fs</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">path </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 expected</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">size_t</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> exception_ptr</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> fsize </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> fs</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">file_size</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">try</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//Use the size</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">catch</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">filesystem_error </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">e</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">e</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">code</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">/*file not found*/</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">path1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&qu=
ot; does not exist.\n"</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">e</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">code</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">/*not a file*/</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> e</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">path1</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">" is not a f=
ile.\n"</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Let's count t=
he ways that this is bad:<br><br>1)
I get redundant information. Because I'm in the function that called=
=20
`file_size`, I probably already know what path I passed. But the=20
exception dutifully passes it back to me.<br><br>2) I get an unneeded=20
memory allocation. Not only did we allocate an exception object, but we=20
allocated the `path` that goes into it. When all I really needed was the
`error_code`. For codebases that need control over allocations, this is
a non-starter; the error code method was superior.<br><br>3) If I=20
cannot use exceptions, this API is binary to me. I can know that an=20
error happened, but there's no way to introspect an `exception_ptr` to=
=20
find out why the error happened. So without throwing, you can't=20
reproduce the code.<br><br>The only people who would use this version of Fi=
leSystem are people who would have just used the throwing version of FileSy=
stem straight up. So what's the point of using expected like this?<br><=
br>This is why `expected<T, exception_ptr>` is not a useful construct=
in general. It can be useful in specific cases, but not as a general way o=
f passing back errors that users have to actually handle.<br><br>If you wan=
t a general mechanism that allows the calling code to decide whether they w=
ant local or non-local error handling, having two separate functions is rea=
lly the best way to do it. You don't hamper the local handling version =
with information and overhead they don't need, and you don't hamper=
the non-local version with objects they don't need (like `expected`).<=
br><br>The only problem I have with FileSystem is that it returns the error=
by parameter instead of by `expected<T, error_code>`. I would still =
want to have duplicate APIs even with `expected`.<br><br>No single error me=
chanism will be all things to all people. And trying to make one will be na=
turally biased towards one side or the other.<br><br>Right now in the C++ w=
orld, we are divided. On the one hand, we have many people who successfully=
use exceptions. On the other, we have people using various ad-hoc error co=
des. We should not treat `expected` as a way to merge these two worlds. Ins=
tead, we should treat `expected` as the proper way to implement error code =
style-handling.<br><br>We need APIs to support both.<br><iframe style=3D"pa=
dding: 0px; position: absolute; top: 0px; left: 0px; width: 774px; height: =
189px; visibility: hidden;" frameborder=3D"0"></iframe>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1291_893178045.1447374522581--
------=_Part_1290_460768859.1447374522580--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 12 Nov 2015 16:45:53 -0800 (PST)
Raw View
------=_Part_2_2100028987.1447375553538
Content-Type: multipart/alternative;
boundary="----=_Part_3_721474998.1447375553538"
------=_Part_3_721474998.1447375553538
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 5:15:48 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 12/11/2015 21:35, Tony V E a =C3=A9crit :=20
> > On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <=20
> > vicent...@wanadoo.fr <javascript:>> wrote:=20
> >=20
> >> Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :=20
> >>=20
> >>> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet=
=20
> >>> Escriba=20
> >>> wrote:=20
> >>>=20
> >>>> Hi,=20
> >>>>=20
> >>>> I would like to re-raise the expected discussion. Beside the=20
> conflicting=20
> >>>> part "managing errors in a different way", that should be covered by=
=20
> a=20
> >>>> specific paper, I would like to open the discussion in order to have=
=20
> a=20
> >>>> better proposal for expected.=20
> >>>>=20
> >>>> There were some concerns about the exception throw when there is no=
=20
> >>>> value.=20
> >>>> I'm wondering if we can do as for basic_string, we can have an=20
> >>>> error_traits=20
> >>>> that define which exception is thrown and that can also do conversio=
n=20
> >>>> from=20
> >>>> exception to errors.=20
> >>>>=20
> >>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Erro=
r>>=20
> >>>>=20
> >>>> we could have a specialization for error_code/error_condition that=
=20
> would=20
> >>>> throw a system_error.=20
> >>>>=20
> >>>> What do you think of this customization?=20
> >>>>=20
> >>>> Suggestion:=20
> >>> Instead of a trait class, if except<T, E> would raise an exception,=
=20
> call:=20
> >>>=20
> >>> [[notreturn]] void std::rethrow(E&&e);=20
> >>>=20
> >> We have rethrow_exception. Are you talking of a new function?=20
> >>=20
> >>> if E is one of std::exception_ptr, std::error_code then std::rethrow=
=20
> does=20
> >>> the obvious thing.=20
> >>>=20
> >> That is, ...=20
> >>=20
> >>> For a generic E std::rethrow performs an unqualified=20
> >>> call to adl_rethrow(e). The default would just throw e.=20
> >>>=20
> >>> It seems that adl calls are the preferred customization method with=
=20
> the=20
> >>> standard. The names are of course to be subjected to bikeshedding.=20
> >>>=20
> >>>=20
> >> I don't mind how we customize the behavior. However, it seems that=20
> there=20
> >> are some people that are against customizing the exception to throw.=
=20
> >> I would like to hear from those that would need to customize the=20
> behavior.=20
> >> What others think of customizing rethrow or rethrow_exception?=20
> >>=20
> >>=20
> >>=20
> > So, obviously, you are getting lots of different opinions from differen=
t=20
> > people.=20
> > For example, Nevin mentioned that he doesn't like basic_string + traits=
=20
> > because no one really uses the traits.=20
> > Other people want/expect that if E is an exception_ptr, it should=20
> rethrow=20
> > it, not throw bad_expected_access<exception_ptr>.=20
> > Some people want it to be consistent, always throw bad_expected_access.=
=20
> > Some people want to avoid exceptions.=20
> > Etc.=20
> >=20
> > And this is how the committee works. Or fails to work, sometimes.=20
> >=20
> > So you think "allow customization - that will make everyone happy". Bu=
t=20
> > even that doesn't, because then those who want simplicity are not happy=
..=20
> >=20
> > We need to look at each facet/opinion carefully. For example, in=20
> general I=20
> > agree with Nevin - basically the committee tends to over-customize when=
=20
> the=20
> > average user doesn't want/need it. But is that the case here? Instead=
=20
> of=20
> > saying "OK I won't do traits", maybe you should say "here's how=20
> expected<>=20
> > is different than basic_string...." ie even if we tend to=20
> over-customize,=20
> > maybe this is a case where customization is useful. Or maybe not.=20
> >=20
> > So how to decide that?=20
> >=20
> > I think we first look at those wanting to avoid exceptions. So they=20
> will=20
> > use expected<T, MyErrorCode> probably equivalent to expected<T, int>. O=
r=20
> > similar.=20
> > OK. Did they avoid exceptions? Well, almost, but not really. If they=
=20
> call=20
> > ex.value() without checking, they may still get a=20
> bad_expected_access<int>=20
> > exception. But note - only if they call it. And I suspect it would be=
=20
> > easy for an implementation to just make that UB when/if the developer=
=20
> shuts=20
> > off exceptions in their compiler.=20
> >=20
> > So, 1. we don't need to define expected.value() to have undefined=20
> behaviour=20
> > - it WILL throw. The only question is what it throws. So let's not=20
> talk=20
> > about IF it throws. Yes it does.=20
> >=20
> > Now, what about expected<T, exception_ptr>. I think I understand=20
> Nicol's=20
> > logic of "if I wanted to use exceptions, I wouldn't have used expected"=
..=20
> > HOWEVER...=20
> I want expected<T, exception_ptr>as storage of future<T>. I believe that=
=20
> the future::then continuation should take an expected<T, exception_ptr>=
=20
> as parameter, not a future<T>.
>
So let's say my promise type was `promise<expected<T, error_code>>`,=20
because I don't plan to propagate exceptions across the boundary. That=20
means my .then continuation takes `expected<expected<T, error_code>,=20
exception_ptr>`.
Um, no. If a user wants to use expected to pass errors across=20
continuations, that's their business. But the API should not *enforce*=20
that. Nor should it enforce the use of `exception_ptr`; that's something=20
users can *choose* to use. But they do not have to.
=20
> >=20
> > Let's look at FileSystem's API. I think it sucks - in the fact that is=
=20
> > double the API, for exception vs non-exception modes. I'd love to=20
> replace=20
> > it with a single API. Can expected<> solve FileSystem's API?=20
> >=20
> > 0. You could argue that it shouldn't be solved. ie there are more=20
> library=20
> > callers than library writers, so don't optimize the API for the library=
=20
> > writers. I don't think I am. I hate the API as a USER. I'd prefer a=
=20
> > single API to make the API easier to understand - for the caller.=20
> >=20
> > So how could expected<> help FileSystem? I think it would work best if=
=20
> > expected threw a *FileSystem* exception on bad access. NOT=20
> > bad_expected_access. If it threw a FileSystem exception, I think you=
=20
> would=20
> > have both APIs in one. (I could be wrong here, it's been years since I=
=20
> > looked at FileSystem closely.)=20
> >=20
> > Do people think that the above is a bad way to make an API? Or should=
=20
> > FileSystem continue to have its dual API? Are there other examples?=20
> >=20
> > If FileSystem is a good example, I think the leads towards _some_ form=
=20
> of=20
> > customization.=20
> >=20
> > As for how to customize:=20
> >=20
> > External: "external" customization, such as expected could call the fre=
e=20
> > function expected_customization_throw_something_given_this_error(E e).=
=20
> (Or=20
> > look up an external traits class.) I don't think this works. Too often=
=20
> E=20
> > will just be int. And FileSystem's ints aren't the same as Windows=20
> HRESULT=20
> > ints, etc. We could always wrap the ints, should we need to?=20
> >=20
> > Magic: expected could just "do the right thing". ie if E is=20
> exception_ptr,=20
> > then rethrow it. if E is derived from exception, throw it. otherwise=
=20
> > throw bad_expected_access<E>.=20
> >=20
> > Always Throw E. Simple. But then you get a bunch of ints being thrown=
..=20
> I=20
> > think this is a no-go option.=20
> >=20
> > Always Throw bad_expected_access<E>. Simple. Possibly unexpected. An=
d=20
> > doesn't "unify" APIs like FileSystem.=20
> >=20
> > Templatized: customize via a traits class *passed in* (which could=20
> default=20
> > to magic or whatever). APIs like FileSystem can turns int errors into=
=20
> > exceptions *at the point when expected.value() is called*. (The "wrap =
E=20
> > with as_error/as_exception" idea would also go here under=20
> "Templatized".)=20
> >=20
> >=20
> > NOTE: for FileSystem, the Magic option means, to unify its APIs, it=20
> would=20
> > need to use exception_ptr (or maybe some E derived from std::exception)=
,=20
> so=20
> > that the "right" FileSystem exception is thrown. This is bad for users=
=20
> > that want to use FileSystem but avoid exceptions.=20
> >=20
> > ----=20
> >=20
> > Conclusions?=20
> > 1. If we find we need customization, I don't think it can be external=
=20
> (too=20
> > many int errors), it needs to be part of the template.=20
> >=20
> > 2. I don't think I like exception_ptr. It doesn't help an API like=20
> > FileSystem that is trying to avoid exceptions. I'd prefer a trait-base=
d=20
> > customization, or throw E when E is derived from std::exception -=20
> because=20
> > you can use std::exception without using exceptions. Can you give me=20
> more=20
> > uses for expected<T, exception_ptr>?=20
> >=20
> > 3. Can someone give more examples (like FileSystem) where customization=
,=20
> > such as "error code turns into specific exception", is useful?=20
> > 3.b is FileSystem a worthy example?=20
> >=20
> >=20
> >=20
> Thanks Tony for the summary.=20
>
> I would like to hear more people. Maybe it is time to move to the LEWG ML=
..=20
>
> Vicente=20
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3_721474998.1447375553538
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, November 12, 2015 at 5:15:48 PM UTC-5, Vicente J. Bote=
t Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 12/11/2015 =
21:35, Tony V E a =C3=A9crit :
<br>> On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <
<br>> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"cAF8GQqZFwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">vicent...@wanadoo.fr</a>> wrote:
<br>>
<br>>> Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :
<br>>>
<br>>>> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente=
J. Botet
<br>>>> Escriba
<br>>>> wrote:
<br>>>>
<br>>>>> Hi,
<br>>>>>
<br>>>>> I would like to re-raise the expected discussion. Besi=
de the conflicting
<br>>>>> part "managing errors in a different way", t=
hat should be covered by a
<br>>>>> specific paper, I would like to open the discussion in=
order to have a
<br>>>>> better proposal for expected.
<br>>>>>
<br>>>>> There were some concerns about the exception throw whe=
n there is no
<br>>>>> value.
<br>>>>> I'm wondering if we can do as for basic_string, we=
can have an
<br>>>>> error_traits
<br>>>>> that define which exception is thrown and that can als=
o do conversion
<br>>>>> from
<br>>>>> exception to errors.
<br>>>>>
<br>>>>> basic_expected<T, Error=3Dexception _ptr, Traits=3D=
error_traits<Error>>
<br>>>>>
<br>>>>> we could have a specialization for error_code/error_co=
ndition that would
<br>>>>> throw a system_error.
<br>>>>>
<br>>>>> What do you think of this customization?
<br>>>>>
<br>>>>> Suggestion:
<br>>>> Instead of a trait class, if except<T, E> would rais=
e an exception, call:
<br>>>>
<br>>>> [[notreturn]] void std::rethrow(E&&e);
<br>>>>
<br>>> We have rethrow_exception. Are you talking of a new function?
<br>>>
<br>>>> if E is one of std::exception_ptr, std::error_code then st=
d::rethrow does
<br>>>> the obvious thing.
<br>>>>
<br>>> That is, ...
<br>>>
<br>>>> For a generic E std::rethrow performs an unqualified
<br>>>> call to adl_rethrow(e). The default would just throw e.
<br>>>>
<br>>>> It seems that adl calls are the preferred customization me=
thod with the
<br>>>> standard. The names are of course to be subjected to bikes=
hedding.
<br>>>>
<br>>>>
<br>>> I don't mind how we customize the behavior. However, it se=
ems that there
<br>>> are some people that are against customizing the exception to =
throw.
<br>>> I would like to hear from those that would need to customize t=
he behavior.
<br>>> What others think of customizing rethrow or rethrow_exception?
<br>>>
<br>>>
<br>>>
<br>> So, obviously, you are getting lots of different opinions from dif=
ferent
<br>> people.
<br>> For example, Nevin mentioned that he doesn't like basic_string=
+ traits
<br>> because no one really uses the traits.
<br>> Other people want/expect that if E is an exception_ptr, it should =
rethrow
<br>> it, not throw bad_expected_access<exception_<wbr>ptr>.
<br>> Some people want it to be consistent, always throw bad_expected_ac=
cess.
<br>> Some people want to avoid exceptions.
<br>> Etc.
<br>>
<br>> And this is how the committee works. =C2=A0Or fails to work, somet=
imes.
<br>>
<br>> So you think "allow customization - that will make everyone h=
appy". =C2=A0But
<br>> even that doesn't, because then those who want simplicity are =
not happy.
<br>>
<br>> We need to look at each facet/opinion carefully. =C2=A0For example=
, in general I
<br>> agree with Nevin - basically the committee tends to over-customize=
when the
<br>> average user doesn't want/need it. =C2=A0But is that the case =
here? =C2=A0Instead of
<br>> saying "OK I won't do traits", maybe you should say =
"here's how expected<>
<br>> is different than basic_string...." =C2=A0ie even if we tend =
to over-customize,
<br>> maybe this is a case where customization is useful. Or maybe not.
<br>>
<br>> So how to decide that?
<br>>
<br>> I think we first look at those wanting to avoid exceptions. =C2=A0=
So they will
<br>> use expected<T, MyErrorCode> probably equivalent to expected=
<T, int>. Or
<br>> similar.
<br>> OK. Did they avoid exceptions? Well, almost, but not really. =C2=
=A0If they call
<br>> ex.value() without checking, they may still get a bad_expected_acc=
ess<int>
<br>> exception. =C2=A0But note - only if they call it. =C2=A0And I susp=
ect it would be
<br>> easy for an implementation to just make that UB when/if the develo=
per shuts
<br>> off exceptions in their compiler.
<br>>
<br>> So, 1. we don't need to define expected.value() to have undefi=
ned behaviour
<br>> - it WILL throw. =C2=A0The only question is what it throws. =C2=A0=
So let's not talk
<br>> about IF it throws. Yes it does.
<br>>
<br>> Now, what about expected<T, exception_ptr>. =C2=A0I think I =
understand Nicol's
<br>> logic of "if I wanted to use exceptions, I wouldn't have =
used expected".
<br>> HOWEVER...
<br>I want expected<T, exception_ptr>as storage of future<T>. I=
believe that=20
<br>the future::then continuation should take an expected<T, exception_p=
tr>=20
<br>as parameter, not a future<T>.<br></blockquote><div><br>So let=
9;s say my promise type was `promise<expected<T, error_code>>`,=
because I don't plan to propagate exceptions across the boundary. That=
means my .then continuation takes `expected<expected<T, error_code&g=
t;, exception_ptr>`.<br><br>Um, no. If a user wants to use expected to p=
ass errors across continuations, that's their business. But the API sho=
uld not <i>enforce</i> that. Nor should it enforce the use of `exception_pt=
r`; that's something users can <i>choose</i> to use. But they do not ha=
ve to.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>> Let's look at FileSystem's API. =C2=A0I think it sucks - i=
n the fact that is
<br>> double the API, for exception vs non-exception modes. =C2=A0I'=
d love to replace
<br>> it with a single API. =C2=A0Can expected<> solve FileSystem&=
#39;s API?
<br>>
<br>> 0. You could argue that it shouldn't be solved. =C2=A0ie there=
are more library
<br>> callers than library writers, so don't optimize the API for th=
e library
<br>> writers. =C2=A0I don't think I am. =C2=A0I hate the API as a U=
SER. =C2=A0I'd prefer a
<br>> single API to make the API easier to understand - for the caller.
<br>>
<br>> So how could expected<> help FileSystem? =C2=A0I think it wo=
uld work best if
<br>> expected threw a *FileSystem* exception on bad access. NOT
<br>> bad_expected_access. =C2=A0If it threw a FileSystem exception, I t=
hink you would
<br>> have both APIs in one. =C2=A0(I could be wrong here, it's been=
years since I
<br>> looked at FileSystem closely.)
<br>>
<br>> Do people think that the above is a bad way to make an API? =C2=A0=
Or should
<br>> FileSystem continue to have its dual API? =C2=A0Are there other ex=
amples?
<br>>
<br>> If FileSystem is a good example, I think the leads towards _some_ =
form of
<br>> customization.
<br>>
<br>> As for how to customize:
<br>>
<br>> External: "external" customization, such as expected cou=
ld call the free
<br>> function expected_customization_throw_<wbr>something_given_this_er=
ror(E e). =C2=A0(Or
<br>> look up an external traits class.) I don't think this works. =
=C2=A0Too often E
<br>> will just be int. =C2=A0And FileSystem's ints aren't the s=
ame as Windows HRESULT
<br>> ints, etc. =C2=A0We could always wrap the ints, should we need to?
<br>>
<br>> Magic: expected could just "do the right thing". =C2=A0i=
e if E is exception_ptr,
<br>> then rethrow it. =C2=A0if E is derived from exception, throw it. =
=C2=A0otherwise
<br>> throw bad_expected_access<E>.
<br>>
<br>> Always Throw E. =C2=A0Simple. =C2=A0But then you get a bunch of in=
ts being thrown. =C2=A0I
<br>> think this is a no-go option.
<br>>
<br>> Always Throw bad_expected_access<E>. =C2=A0Simple. =C2=A0Pos=
sibly unexpected. =C2=A0And
<br>> doesn't "unify" APIs like FileSystem.
<br>>
<br>> Templatized: customize via a traits class *passed in* (which could=
default
<br>> to magic or whatever). =C2=A0APIs like FileSystem can turns int er=
rors into
<br>> exceptions *at the point when expected.value() is called*. =C2=A0(=
The "wrap E
<br>> with as_error/as_exception" idea would also go here under &qu=
ot;Templatized".)
<br>>
<br>>
<br>> NOTE: for FileSystem, the Magic option means, to unify its APIs, i=
t would
<br>> need to use exception_ptr (or maybe some E derived from std::excep=
tion), so
<br>> that the "right" FileSystem exception is thrown. =C2=A0T=
his is bad for users
<br>> that want to use FileSystem but avoid exceptions.
<br>>
<br>> ----
<br>>
<br>> Conclusions?
<br>> 1. If we find we need customization, I don't think it can be e=
xternal (too
<br>> many int errors), it needs to be part of the template.
<br>>
<br>> 2. I don't think I like exception_ptr. =C2=A0It doesn't he=
lp an API like
<br>> FileSystem that is trying to avoid exceptions. =C2=A0I'd prefe=
r a trait-based
<br>> customization, or throw E when E is derived from std::exception - =
because
<br>> you can use std::exception without using exceptions. Can you give =
me more
<br>> uses for expected<T, exception_ptr>?
<br>>
<br>> 3. Can someone give more examples (like FileSystem) where customiz=
ation,
<br>> such as "error code turns into specific exception", is u=
seful?
<br>> 3.b is FileSystem a worthy example?
<br>>
<br>>
<br>>
<br>Thanks Tony for the summary.
<br>
<br>I would like to hear more people. Maybe it is time to move to the LEWG =
ML.
<br>
<br>Vicente
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3_721474998.1447375553538--
------=_Part_2_2100028987.1447375553538--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 13 Nov 2015 08:51:00 +0100
Raw View
This is a multi-part message in MIME format.
--------------060706030509060702050308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 13/11/2015 01:28, Nicol Bolas a =C3=A9crit :
> On Thursday, November 12, 2015 at 3:35:06 PM UTC-5, Tony V E wrote:
>> On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <
>> vicent...@wanadoo.fr> wrote:
>>
>>>
>>>
>> Other people want/expect that if E is an exception_ptr, it should rethro=
w
>> it, not throw bad_expected_access<exception_ptr>.
>>
> Actually, outside of the OP, I think you're the first one who's come out =
in
> favor of the position that `expected<T, exception_ptr>` should rethrow th=
e
> exception_ptr in `value()`. Everyone else has either said no or expressed=
a
> desire for a different customization mechanism.
> =20
I don't deduce this from what Tony said.
>> So how could expected<> help FileSystem? I think it would work best if
>> expected threw a *FileSystem* exception on bad access. NOT
>> bad_expected_access. If it threw a FileSystem exception, I think you wo=
uld
>> have both APIs in one. (I could be wrong here, it's been years since I
>> looked at FileSystem closely.)
>>
>> Do people think that the above is a bad way to make an API? Or should
>> FileSystem continue to have its dual API? Are there other examples?
>>
> Here's the problem. Let's say I have this code, using the FileSystem TS:
I believe that no body has proposed yet to use expected<T,=20
exception_ptr> for FileSystem TS.
>
> void func(const fs::path &p)
> {
> ...
> error_code ec;
> auto fsize =3D fs::file_size(p, &ec);
> if(ec)
> {
> if(ec =3D=3D /*file not found*/) { std::cout << p << " does not exis=
t.\n"; }
> if(ec =3D=3D /*not a file*/) { std::cout << p << " is not a file.\n"=
; }
> return;
> }
> //Use the size.
> }
>
> It's verbose, but fairly simple to deal with. If there's an error, I prin=
t
> out a message based on that error.
>
> Now, let's do it the expected<T, exception_ptr> way:
>
> void func(const fs::path &p)
> {
> ...
> expected<size_t, exception_ptr> fsize =3D fs::file_size(p);
>
> try
> {
> //Use the size
> }
> catch(std::filesystem_error &e)
> {
> if(e.code() =3D=3D /*file not found*/) { std::cout << e.path1() << "=
does
> not exist.\n"; }
> if(e.code() =3D=3D /*not a file*/) { std::cout << e.path1() << " is =
not a
> file.\n"; }
> return;
> }
> }
>
> Let's count the ways that this is bad:
>
> 1) I get redundant information. Because I'm in the function that called
> `file_size`, I probably already know what path I passed. But the exceptio=
n
> dutifully passes it back to me.
>
> 2) I get an unneeded memory allocation. Not only did we allocate an
> exception object, but we allocated the `path` that goes into it. When all=
I
> really needed was the `error_code`. For codebases that need control over
> allocations, this is a non-starter; the error code method was superior.
>
> 3) If I cannot use exceptions, this API is binary to me. I can know that =
an
> error happened, but there's no way to introspect an `exception_ptr` to fi=
nd
> out why the error happened. So without throwing, you can't reproduce the
> code.
>
> The only people who would use this version of FileSystem are people who
> would have just used the throwing version of FileSystem straight up. So
> what's the point of using expected like this?
>
> This is why `expected<T, exception_ptr>` is not a useful construct in
> general. It can be useful in specific cases, but not as a general way of
> passing back errors that users have to actually handle.
>
> If you want a general mechanism that allows the calling code to decide
> whether they want local or non-local error handling, having two separate
> functions is really the best way to do it. You don't hamper the local
> handling version with information and overhead they don't need, and you
> don't hamper the non-local version with objects they don't need (like
> `expected`).
>
> The only problem I have with FileSystem is that it returns the error by
> parameter instead of by `expected<T, error_code>`. I would still want to
> have duplicate APIs even with `expected`.
>
> No single error mechanism will be all things to all people. And trying to
> make one will be naturally biased towards one side or the other.
>
> Right now in the C++ world, we are divided. On the one hand, we have many
> people who successfully use exceptions. On the other, we have people usin=
g
> various ad-hoc error codes. We should not treat `expected` as a way to
> merge these two worlds. Instead, we should treat `expected` as the proper
> way to implement error code style-handling.
>
> We need APIs to support both.
>
Thanks Nicol for this concrete example of local error handling. I will=20
come back later.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------060706030509060702050308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 13/11/2015 01:28, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:0907a269-4ae4-463e-aceb-74c007e073e7@isocpp.org"
type=3D"cite">
<pre wrap=3D"">On Thursday, November 12, 2015 at 3:35:06 PM UTC-5, To=
ny V E wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
On Thu, Nov 12, 2015 at 2:05 PM, Vicente J. Botet Escriba <
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:vicent...@wanadoo.fr">=
vicent...@wanadoo.fr</a>> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
</pre>
</blockquote>
<pre wrap=3D"">Other people want/expect that if E is an exception_p=
tr, it should rethrow=20
it, not throw bad_expected_access<exception_ptr>.
</pre>
</blockquote>
<pre wrap=3D"">
Actually, outside of the OP, I think you're the first one who's come out in=
=20
favor of the position that `expected<T, exception_ptr>` should rethro=
w the=20
exception_ptr in `value()`. Everyone else has either said no or expressed a=
=20
desire for a different customization mechanism.
=20
</pre>
</blockquote>
I don't deduce this from what Tony said. <br>
<blockquote
cite=3D"mid:0907a269-4ae4-463e-aceb-74c007e073e7@isocpp.org"
type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
So how could expected<> help FileSystem? I think it would work best =
if=20
expected threw a *FileSystem* exception on bad access. NOT=20
bad_expected_access. If it threw a FileSystem exception, I think you would=
=20
have both APIs in one. (I could be wrong here, it's been years since I=20
looked at FileSystem closely.)
Do people think that the above is a bad way to make an API? Or should=20
FileSystem continue to have its dual API? Are there other examples?
</pre>
</blockquote>
<pre wrap=3D"">
Here's the problem. Let's say I have this code, using the FileSystem TS:</p=
re>
</blockquote>
I believe that no body has proposed yet to use expected<T,
exception_ptr> for FileSystem TS.<br>
<blockquote
cite=3D"mid:0907a269-4ae4-463e-aceb-74c007e073e7@isocpp.org"
type=3D"cite">
<pre wrap=3D"">
void func(const fs::path &p)
{
...
error_code ec;
auto fsize =3D fs::file_size(p, &ec);
if(ec)
{
if(ec =3D=3D /*file not found*/) { std::cout << p << " does=
not exist.\n"; }
if(ec =3D=3D /*not a file*/) { std::cout << p << " is not a=
file.\n"; }
return;
}
//Use the size.
}
It's verbose, but fairly simple to deal with. If there's an error, I print=
=20
out a message based on that error.
Now, let's do it the expected<T, exception_ptr> way:
void func(const fs::path &p)
{
...
expected<size_t, exception_ptr> fsize =3D fs::file_size(p);
try
{
//Use the size
}
catch(std::filesystem_error &e)
{
if(e.code() =3D=3D /*file not found*/) { std::cout << e.path1() &=
lt;< " does=20
not exist.\n"; }
if(e.code() =3D=3D /*not a file*/) { std::cout << e.path1() <&=
lt; " is not a=20
file.\n"; }
return;
}
}
Let's count the ways that this is bad:
1) I get redundant information. Because I'm in the function that called=20
`file_size`, I probably already know what path I passed. But the exception=
=20
dutifully passes it back to me.
2) I get an unneeded memory allocation. Not only did we allocate an=20
exception object, but we allocated the `path` that goes into it. When all I=
=20
really needed was the `error_code`. For codebases that need control over=20
allocations, this is a non-starter; the error code method was superior.
3) If I cannot use exceptions, this API is binary to me. I can know that an=
=20
error happened, but there's no way to introspect an `exception_ptr` to find=
=20
out why the error happened. So without throwing, you can't reproduce the=20
code.
The only people who would use this version of FileSystem are people who=20
would have just used the throwing version of FileSystem straight up. So=20
what's the point of using expected like this?
This is why `expected<T, exception_ptr>` is not a useful construct in=
=20
general. It can be useful in specific cases, but not as a general way of=20
passing back errors that users have to actually handle.
If you want a general mechanism that allows the calling code to decide=20
whether they want local or non-local error handling, having two separate=20
functions is really the best way to do it. You don't hamper the local=20
handling version with information and overhead they don't need, and you=20
don't hamper the non-local version with objects they don't need (like=20
`expected`).
The only problem I have with FileSystem is that it returns the error by=20
parameter instead of by `expected<T, error_code>`. I would still want=
to=20
have duplicate APIs even with `expected`.
No single error mechanism will be all things to all people. And trying to=
=20
make one will be naturally biased towards one side or the other.
Right now in the C++ world, we are divided. On the one hand, we have many=
=20
people who successfully use exceptions. On the other, we have people using=
=20
various ad-hoc error codes. We should not treat `expected` as a way to=20
merge these two worlds. Instead, we should treat `expected` as the proper=
=20
way to implement error code style-handling.
We need APIs to support both.
</pre>
</blockquote>
<br>
<font size=3D"+1">Thanks Nicol for this concrete example of local
error handling. I will come back later.<br>
</font><br>
<font size=3D"+1"></font><font size=3D"+1"><br>
Vicente<br>
<br>
<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------060706030509060702050308--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Fri, 13 Nov 2015 01:57:44 -0800 (PST)
Raw View
------=_Part_80_567470747.1447408664522
Content-Type: multipart/alternative;
boundary="----=_Part_81_2001188768.1447408664522"
------=_Part_81_2001188768.1447408664522
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 7:05:50 PM UTC, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 12/11/2015 16:26, Giovanni Piero Deretta a =C3=A9crit :=20
> > On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Botet=20
> Escriba=20
> > wrote:=20
> >> Hi,=20
> >>=20
> >> I would like to re-raise the expected discussion. Beside the=20
> conflicting=20
> >> part "managing errors in a different way", that should be covered by a=
=20
> >> specific paper, I would like to open the discussion in order to have a=
=20
> >> better proposal for expected.=20
> >>=20
> >> There were some concerns about the exception throw when there is no=20
> value.=20
> >> I'm wondering if we can do as for basic_string, we can have an=20
> error_traits=20
> >> that define which exception is thrown and that can also do conversion=
=20
> from=20
> >> exception to errors.=20
> >>=20
> >> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_traits<Error>=
>=20
> >>=20
> >> we could have a specialization for error_code/error_condition that=20
> would=20
> >> throw a system_error.=20
> >>=20
> >> What do you think of this customization?=20
> >>=20
> > Suggestion:=20
> >=20
> > Instead of a trait class, if except<T, E> would raise an exception,=20
> call:=20
> >=20
> > [[notreturn]] void std::rethrow(E&&e);=20
> We have rethrow_exception. Are you talking of a new function?=20
>
>
yes, a new function. I just reused the name you used in the trait. Other=20
random names: std::to_exception, std::transogrify.
=20
>
> > if E is one of std::exception_ptr, std::error_code then std::rethrow=20
> does=20
> > the obvious thing.=20
> That is, ...=20
>
Sorry, :), I mean the same mapping as done by the traits: passing=20
std::error_code would throw a system error, passing std::exception pointer=
=20
would call rethrow_exception on it.
=20
> > For a generic E std::rethrow performs an unqualified=20
> > call to adl_rethrow(e). The default would just throw e.=20
> >=20
> > It seems that adl calls are the preferred customization method with the=
=20
> > standard. The names are of course to be subjected to bikeshedding.=20
> >=20
>
> I don't mind how we customize the behavior. However, it seems that there=
=20
> are some people that are against customizing the exception to throw.=20
>
So, we some time ago about std::expected being semantically equivalent to=
=20
statically checked exceptions. I'm not going to argue again about making=20
the syntax also equivalent, but I think that the observation could be a=20
guide in design. =20
To reiterate I see 'expected<R, E> do_something(T);' as a function that is=
=20
logically from T -> R which will raise a statically checked exception E on=
=20
error. =20
expected<R,E>::value bridges the gap from the statically checked exception=
=20
model the usual C++ dynamic exception=20
model, so from a purity point of view I would expect it to throw exactly E.=
=20
In practice things are a bit more complicated: in c++ we capture exceptions=
=20
by type, not by value, so it useful to be able to customize this mapping.
Finally there is std::exception_ptr; this is the reverse when we want to go=
=20
back from the dynamic exception model to the static model, or in a mixed=20
scenario. As we have lost the actual type of the original exception the=20
best we can do is hide it in a type erasure wrapper.
-- gpd
Can be interpreted as a function=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_81_2001188768.1447408664522
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 12, 2015 at 7:05:50 PM UTC, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 12/11/2015 16:26, Gio=
vanni Piero Deretta a =C3=A9crit :
<br>> On Wednesday, November 11, 2015 at 8:01:19 PM UTC, Vicente J. Bote=
t Escriba
<br>> wrote:
<br>>> Hi,
<br>>>
<br>>> I would like to re-raise the expected discussion. Beside the c=
onflicting
<br>>> part "managing errors in a different way", that shou=
ld be covered by a
<br>>> specific paper, I would like to open the discussion in order t=
o have a
<br>>> better proposal for expected.
<br>>>
<br>>> There were some concerns about the exception throw when there =
is no value.
<br>>> I'm wondering if we can do as for basic_string, we can hav=
e an error_traits
<br>>> that define which exception is thrown and that can also do con=
version from
<br>>> exception to errors.
<br>>>
<br>>> basic_expected<T, Error=3Dexception _ptr, Traits=3Derror_tr=
aits<Error>>
<br>>>
<br>>> we could have a specialization for error_code/error_condition =
that would
<br>>> throw a system_error.
<br>>>
<br>>> What do you think of this customization?
<br>>>
<br>> Suggestion:
<br>>
<br>> Instead of a trait class, if except<T, E> would raise an exc=
eption, call:
<br>>
<br>> [[notreturn]] void std::rethrow(E&&e);
<br>We have rethrow_exception. Are you talking of a new function?
<br><br></blockquote><div><br>yes, a new function. I just reused the name y=
ou used in the trait. Other random names: std::to_exception, std::transogri=
fy.<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;">
<br>> if E is one of std::exception_ptr, std::error_code then std::rethr=
ow does
<br>> the obvious thing.
<br>That is, ...
<br></blockquote><div><br>Sorry, :), I mean the same mapping as done by the=
traits: passing std::error_code would throw a system error, passing std::e=
xception pointer would call rethrow_exception on it.<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">> For a generic E std::rethrow per=
forms an unqualified
<br>> call to adl_rethrow(e). The default would just throw e.
<br>>
<br>> It seems that adl calls are the preferred customization method wit=
h the
<br>> standard. The names are of course to be subjected to bikeshedding.
<br>>
<br>
<br>I don't mind how we customize the behavior. However, it seems that =
there=20
<br>are some people that are against customizing the exception to throw.
<br></blockquote><div><br></div>So, we some time ago about std::expected be=
ing semantically equivalent to statically checked exceptions. I'm not g=
oing to argue again about making the syntax also equivalent, but I think th=
at the observation could be a guide in design.=C2=A0 <br><br>To reiterate I=
see 'expected<R, E> do_something(T);' as a function that is =
logically from T -> R which will raise a statically checked exception E =
on error.=C2=A0 <br><br>expected<R,E>::value bridges the gap from the=
statically checked exception model the usual C++ dynamic exception <br>mod=
el, so from a purity point of view I would expect it to throw exactly E. In=
practice things are a bit more complicated: in c++ we capture exceptions b=
y type, not by value, so it useful to be able to customize this mapping.<br=
><br>Finally there is std::exception_ptr; this is the reverse when we want =
to go back from the dynamic exception model to the static model, or in a mi=
xed scenario. As we have lost the actual type of the original exception the=
best we can do is hide it in a type erasure wrapper.<br><br>-- gpd<br>Can =
be interpreted as a function <br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_81_2001188768.1447408664522--
------=_Part_80_567470747.1447408664522--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Fri, 13 Nov 2015 02:13:43 -0800 (PST)
Raw View
------=_Part_11058_1544155335.1447409623233
Content-Type: multipart/alternative;
boundary="----=_Part_11059_369275142.1447409623233"
------=_Part_11059_369275142.1447409623233
Content-Type: text/plain; charset=UTF-8
Hi Tony,
I strongly agree with most of what you wrote. Just wanted to add a couple
of comments.
On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
>
> So, obviously, you are getting lots of different opinions from different
> people.
> For example, Nevin mentioned that he doesn't like basic_string + traits
> because no one really uses the traits.
> Other people want/expect that if E is an exception_ptr, it should rethrow
> it, not throw bad_expected_access<exception_ptr>.
> Some people want it to be consistent, always throw bad_expected_access.
> Some people want to avoid exceptions.
> Etc.
>
> And this is how the committee works. Or fails to work, sometimes.
>
> So you think "allow customization - that will make everyone happy". But
> even that doesn't, because then those who want simplicity are not happy.
>
> We need to look at each facet/opinion carefully. For example, in general
> I agree with Nevin - basically the committee tends to over-customize when
> the average user doesn't want/need it. But is that the case here? Instead
> of saying "OK I won't do traits", maybe you should say "here's how
> expected<> is different than basic_string...." ie even if we tend to
> over-customize, maybe this is a case where customization is useful. Or
> maybe not.
>
> So how to decide that?
>
> I think we first look at those wanting to avoid exceptions. So they will
> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or
> similar.
> OK. Did they avoid exceptions? Well, almost, but not really. If they call
> ex.value() without checking, they may still get a bad_expected_access<int>
> exception. But note - only if they call it. And I suspect it would be
> easy for an implementation to just make that UB when/if the developer shuts
> off exceptions in their compiler.
>
> So, 1. we don't need to define expected.value() to have undefined
> behaviour - it WILL throw. The only question is what it throws. So let's
> not talk about IF it throws. Yes it does.
>
>
I'm also strongly in favor with ::value throwing an exception.
> Now, what about expected<T, exception_ptr>. I think I understand Nicol's
> logic of "if I wanted to use exceptions, I wouldn't have used expected".
> HOWEVER...
>
> Let's look at FileSystem's API. I think it sucks - in the fact that is
> double the API, for exception vs non-exception modes. I'd love to replace
> it with a single API. Can expected<> solve FileSystem's API?
>
> 0. You could argue that it shouldn't be solved. ie there are more library
> callers than library writers, so don't optimize the API for the library
> writers. I don't think I am. I hate the API as a USER. I'd prefer a
> single API to make the API easier to understand - for the caller.
>
> So how could expected<> help FileSystem? I think it would work best if
> expected threw a *FileSystem* exception on bad access. NOT
> bad_expected_access. If it threw a FileSystem exception, I think you would
> have both APIs in one. (I could be wrong here, it's been years since I
> looked at FileSystem closely.)
>
> Do people think that the above is a bad way to make an API? Or should
> FileSystem continue to have its dual API? Are there other examples?
>
>
In an ideal world yes; the expected<> API would be the only one.
> If FileSystem is a good example, I think the leads towards _some_ form of
> customization.
>
> As for how to customize:
>
> External: "external" customization, such as expected could call the free
> function expected_customization_throw_something_given_this_error(E e). (Or
> look up an external traits class.) I don't think this works. Too often E
> will just be int. And FileSystem's ints aren't the same as Windows HRESULT
> ints, etc. We could always wrap the ints, should we need to?
>
at the very least you do a favour to your users and wrap your ints error
into (empty) strongly typed enums. This seems pretty basic API design.
>
> Magic: expected could just "do the right thing". ie if E is
> exception_ptr, then rethrow it. if E is derived from exception, throw it.
> otherwise throw bad_expected_access<E>.
>
> Always Throw E. Simple. But then you get a bunch of ints being thrown.
> I think this is a no-go option.
>
> Always Throw bad_expected_access<E>. Simple. Possibly unexpected. And
> doesn't "unify" APIs like FileSystem.
>
> Templatized: customize via a traits class *passed in* (which could default
> to magic or whatever). APIs like FileSystem can turns int errors into
> exceptions *at the point when expected.value() is called*. (The "wrap E
> with as_error/as_exception" idea would also go here under "Templatized".)
>
>
> NOTE: for FileSystem, the Magic option means, to unify its APIs, it would
> need to use exception_ptr (or maybe some E derived from std::exception), so
> that the "right" FileSystem exception is thrown. This is bad for users
> that want to use FileSystem but avoid exceptions.
>
>
This I do not understand why would you need exception_ptr? Either only use
error codes or, better return an expected<T, std::variant<E1, E2...> >. In
fact expected should have first class support for variant.
> ----
>
> Conclusions?
> 1. If we find we need customization, I don't think it can be external (too
> many int errors), it needs to be part of the template.
>
I strongly believe that expected should discourage int errors.
>
> 2. I don't think I like exception_ptr. It doesn't help an API like
> FileSystem that is trying to avoid exceptions. I'd prefer a trait-based
> customization, or throw E when E is derived from std::exception - because
> you can use std::exception without using exceptions. Can you give me more
> uses for expected<T, exception_ptr>?
>
>
an std::rethrow could map error codes to exception hierarchies.
> 3. Can someone give more examples (like FileSystem) where customization,
> such as "error code turns into specific exception", is useful?
>
anything that touches OS APIs: networking, process management, credentials,
etc...
> 3.b is FileSystem a worthy example?
>
>
of course.
-- gpd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_11059_369275142.1447409623233
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Tony,<br><br>I strongly agree with most of what you wro=
te. Just wanted to add a couple of comments.<br><br>On Thursday, November 1=
2, 2015 at 8:35:06 PM UTC, Tony V E wrote:<br><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><br></div>So, obviously, you are getting lots of different opinions from =
different people.<br></div><div>For example, Nevin mentioned that he doesn&=
#39;t like basic_string + traits because no one really uses the traits.<br>=
</div><div>Other people want/expect that if E is an exception_ptr, it shoul=
d rethrow it, not throw bad_expected_access<exception_<wbr>ptr>.<br><=
/div><div>Some people want it to be consistent, always throw bad_expected_a=
ccess.<br></div><div>Some people want to avoid exceptions.<br>Etc.<br><br><=
/div><div>And this is how the committee works.=C2=A0 Or fails to work, some=
times.<br><br></div><div>So you think "allow customization - that will=
make everyone happy".=C2=A0 But even that doesn't, because then t=
hose who want simplicity are not happy.<br><br></div><div>We need to look a=
t each facet/opinion carefully.=C2=A0 For example, in general I agree with =
Nevin - basically the committee tends to over-customize when the average us=
er doesn't want/need it.=C2=A0 But is that the case here?=C2=A0 Instead=
of saying "OK I won't do traits", maybe you should say "=
;here's how expected<> is different than basic_string...."=
=C2=A0 ie even if we tend to over-customize, maybe this is a case where cus=
tomization is useful. Or maybe not.<br><br></div><div>So how to decide that=
?<br><br></div><div>I think we first look at those wanting to avoid excepti=
ons.=C2=A0 So they will use expected<T, MyErrorCode> probably equival=
ent to expected<T, int>. Or similar.<br></div><div>OK. Did they avoid=
exceptions? Well, almost, but not really.=C2=A0 If they call ex.value() wi=
thout checking, they may still get a bad_expected_access<int> excepti=
on.=C2=A0 But note - only if they call it.=C2=A0 And I suspect it would be =
easy for an implementation to just make that UB when/if the developer shuts=
off exceptions in their compiler.<br><br></div><div>So, 1. we don't ne=
ed to define expected.value() to have undefined behaviour - it WILL throw.=
=C2=A0 The only question is what it throws.=C2=A0 So let's not talk abo=
ut IF it throws. Yes it does.<br><br></div></div></blockquote><div><br>I=
9;m also strongly in favor with ::value throwing an exception.<br>=C2=A0</d=
iv><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></div=
><div>Now, what about expected<T, exception_ptr>.=C2=A0 I think I und=
erstand Nicol's logic of "if I wanted to use exceptions, I wouldn&=
#39;t have used expected".<br></div><div>HOWEVER...<br><br></div><div>=
Let's look at FileSystem's API.=C2=A0 I think it sucks - in the fac=
t that is double the API, for exception vs non-exception modes.=C2=A0 I'=
;d love to replace it with a single API.=C2=A0 Can expected<> solve F=
ileSystem's API?<br><br></div><div>0. You could argue that it shouldn&#=
39;t be solved.=C2=A0 ie there are more library callers than library writer=
s, so don't optimize the API for the library writers.=C2=A0 I don't=
think I am.=C2=A0 I hate the API as a USER.=C2=A0 I'd prefer a single =
API to make the API easier to understand - for the caller.<br></div><div><b=
r></div><div>So how could expected<> help FileSystem?=C2=A0 I think i=
t would work best if expected threw a *FileSystem* exception on bad access.=
NOT bad_expected_access.=C2=A0 If it threw a FileSystem exception, I think=
you would have both APIs in one.=C2=A0 (I could be wrong here, it's be=
en years since I looked at FileSystem closely.)<br><br></div><div>Do people=
think that the above is a bad way to make an API?=C2=A0 Or should FileSyst=
em continue to have its dual API?=C2=A0 Are there other examples?<br><br></=
div></div></blockquote><div><br>In an ideal world yes; the expected<>=
API would be the only one. <br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div></div><div>If FileSystem is a good exam=
ple, I think the leads towards _some_ form of customization.<br><br></div><=
div>As for how to customize:<br><br></div><div>External: "external&quo=
t; customization, such as expected could call the free function expected_cu=
stomization_throw_<wbr>something_given_this_error(E e).=C2=A0 (Or look up a=
n external traits class.) I don't think this works.=C2=A0 Too often E w=
ill just be int.=C2=A0 And FileSystem's ints aren't the same as Win=
dows HRESULT ints, etc.=C2=A0 We could always wrap the ints, should we need=
to?<br></div></div></blockquote><div><br>at the very least you do a favour=
to your users and wrap your ints error into (empty) strongly typed enums. =
This seems pretty basic API design.<br>=C2=A0</div><blockquote class=3D"gma=
il_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>Magic: expected c=
ould just "do the right thing".=C2=A0 ie if E is exception_ptr, t=
hen rethrow it.=C2=A0 if E is derived from exception, throw it.=C2=A0 other=
wise throw bad_expected_access<E>.<br><br></div><div>Always Throw E.=
=C2=A0 Simple.=C2=A0 But then you get a bunch of ints being thrown.=C2=A0 I=
think this is a no-go option.<br><br></div><div>Always Throw bad_expected_=
access<E>.=C2=A0 Simple.=C2=A0 Possibly unexpected.=C2=A0 And doesn&#=
39;t "unify" APIs like FileSystem.<br><br></div><div>Templatized:=
customize via a traits class *passed in* (which could default to magic or =
whatever).=C2=A0 APIs like FileSystem can turns int errors into exceptions =
*at the point when expected.value() is called*.=C2=A0 (The "wrap E wit=
h as_error/as_exception" idea would also go here under "Templatiz=
ed".)<br></div><div><br><br>NOTE: for FileSystem, the Magic option mea=
ns, to unify its APIs, it would need to=20
use exception_ptr (or maybe some E derived from std::exception), so that th=
e "right" FileSystem exception is thrown.=C2=A0=20
This is bad for users that want to use FileSystem but avoid exceptions.<br>=
<br></div></div></blockquote><div><br>This I do not understand why would yo=
u need exception_ptr? Either only use error codes or, better return an expe=
cted<T, std::variant<E1, E2...> >. In fact expected should have=
first class support for variant. <br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>----<br><br></div><div>Conclusion=
s?<br></div><div>1. If we find we need customization, I don't think it =
can be external (too many int errors), it needs to be part of the template.=
<br></div></div></blockquote><div><br>I strongly believe that expected shou=
ld discourage int errors. <br>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div><br></div><div>2. I don't think I lik=
e exception_ptr.=C2=A0 It doesn't help an API like FileSystem that is t=
rying to avoid exceptions.=C2=A0 I'd prefer a trait-based customization=
, or throw E when E is derived from std::exception - because you can use st=
d::exception without using exceptions. Can you give me more uses for expect=
ed<T, exception_ptr>?<br></div><div><br></div></div></blockquote><div=
><br>an std::rethrow could map error codes to exception hierarchies.<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
></div><div>3. Can someone give more examples (like FileSystem) where custo=
mization, such as "error code turns into specific exception", is =
useful?<br></div></div></blockquote><div><br>anything that touches OS APIs:=
networking, process management, credentials, etc...<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>3.b =
is FileSystem a worthy example?<br><br></div></div></blockquote><div><br>of=
course.<br>=C2=A0<br><br>-- gpd<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_11059_369275142.1447409623233--
------=_Part_11058_1544155335.1447409623233--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Nov 2015 10:08:40 -0800 (PST)
Raw View
------=_Part_11515_827818036.1447438120368
Content-Type: multipart/alternative;
boundary="----=_Part_11516_1691810947.1447438120368"
------=_Part_11516_1691810947.1447438120368
Content-Type: text/plain; charset=UTF-8
On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero Deretta
wrote:
>
> Hi Tony,
>
> I strongly agree with most of what you wrote. Just wanted to add a couple
> of comments.
>
> On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
>
>>
>> So, obviously, you are getting lots of different opinions from different
>> people.
>> For example, Nevin mentioned that he doesn't like basic_string + traits
>> because no one really uses the traits.
>> Other people want/expect that if E is an exception_ptr, it should rethrow
>> it, not throw bad_expected_access<exception_ptr>.
>> Some people want it to be consistent, always throw bad_expected_access.
>> Some people want to avoid exceptions.
>> Etc.
>>
>> And this is how the committee works. Or fails to work, sometimes.
>>
>> So you think "allow customization - that will make everyone happy". But
>> even that doesn't, because then those who want simplicity are not happy.
>>
>> We need to look at each facet/opinion carefully. For example, in general
>> I agree with Nevin - basically the committee tends to over-customize when
>> the average user doesn't want/need it. But is that the case here? Instead
>> of saying "OK I won't do traits", maybe you should say "here's how
>> expected<> is different than basic_string...." ie even if we tend to
>> over-customize, maybe this is a case where customization is useful. Or
>> maybe not.
>>
>> So how to decide that?
>>
>> I think we first look at those wanting to avoid exceptions. So they will
>> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or
>> similar.
>> OK. Did they avoid exceptions? Well, almost, but not really. If they
>> call ex.value() without checking, they may still get a
>> bad_expected_access<int> exception. But note - only if they call it. And
>> I suspect it would be easy for an implementation to just make that UB
>> when/if the developer shuts off exceptions in their compiler.
>>
>> So, 1. we don't need to define expected.value() to have undefined
>> behaviour - it WILL throw. The only question is what it throws. So let's
>> not talk about IF it throws. Yes it does.
>>
>>
> I'm also strongly in favor with ::value throwing an exception.
>
Generally speaking, nobody is opposed to `value` throwing. Even the one
person who didn't like it said that it was fine due to consistency with
similar interfaces.
The question is what it throws. Should it throw a single thing consistently
for all `E`, or should it have special cases? And if it should have special
cases, should they be customizable? And how do we customize them?
Behind all of these is the most important of all: what the *purpose* of
this function not throwing a consistent type?
Thus far, the main reason people give for wanting `value` to throw
arbitrary things is to be able to merge non-local error interfaces with
local error interfaces. So if the caller wants to catch the exception, they
say `.value()` and just catch it wherever. If they do not, then the user
uses operator* or otherwise manually test it.
My feeling is that any such merger will hurt one kind of error handling or
the other. And thus, while the idea of merging is well-intensioned, it just
leads to too many problems.
Magic: expected could just "do the right thing". ie if E is exception_ptr,
>> then rethrow it. if E is derived from exception, throw it. otherwise
>> throw bad_expected_access<E>.
>>
>> Always Throw E. Simple. But then you get a bunch of ints being thrown.
>> I think this is a no-go option.
>>
>> Always Throw bad_expected_access<E>. Simple. Possibly unexpected. And
>> doesn't "unify" APIs like FileSystem.
>>
>> Templatized: customize via a traits class *passed in* (which could
>> default to magic or whatever). APIs like FileSystem can turns int errors
>> into exceptions *at the point when expected.value() is called*. (The "wrap
>> E with as_error/as_exception" idea would also go here under "Templatized".)
>>
>>
>> NOTE: for FileSystem, the Magic option means, to unify its APIs, it would
>> need to use exception_ptr (or maybe some E derived from std::exception), so
>> that the "right" FileSystem exception is thrown. This is bad for users
>> that want to use FileSystem but avoid exceptions.
>>
>>
> This I do not understand why would you need exception_ptr?
>
What Tony (and apparently yourself) want is to have APIs provide single
functions that don't throw. And therefore, any throwing of exceptions is
based on how the caller uses the `expected` return value. So instead of
having a `filesystem::file_size` function with two overloads, you just have
one that returns an `expected<size_t, E>`
The question is what `E` should be.
Right now, `filesystem_error` provides rich information about why the error
happened. Information that is useful to users who catch the exception,
possibly far from the throwing location. So if you want to merge the
interfaces without the exception users losing information, you must return
an `expected<T, exception_ptr>`. Or at the very least, `expected<T,
filesystem_error>`.
> Either only use error codes or, better return an expected<T,
> std::variant<E1, E2...> >. In fact expected should have first class support
> for variant.
>
>
----
>>
>> Conclusions?
>> 1. If we find we need customization, I don't think it can be external
>> (too many int errors), it needs to be part of the template.
>>
>
> I strongly believe that expected should discourage int errors.
>
"strongly discouraging" things will not stop them from happening.
`expected` should work with the reality we have, not the one we'd prefer.
2. I don't think I like exception_ptr. It doesn't help an API like
>> FileSystem that is trying to avoid exceptions. I'd prefer a trait-based
>> customization, or throw E when E is derived from std::exception - because
>> you can use std::exception without using exceptions. Can you give me more
>> uses for expected<T, exception_ptr>?
>>
>>
> an std::rethrow could map error codes to exception hierarchies.
>
OK, let's say we have some customization scheme that would convert
`error_code` to an exception.
Look at `filesystem_error
<http://en.cppreference.com/w/cpp/experimental/fs/filesystem_error>`. It
has 2 path objects; these exists so that users catching the exception can
actually tell what caused the exception. After all, the location of the
catch can be very distant from the immediate caller, so any paths passed to
the throwing function may have long since been destroyed. Storing the
path(s) that caused the error makes sense; it provides the catcher with
vital and useful information.
`std::error_code` has no such information. So whatever customization scheme
you might envision to convert `error_code` into an exception would be
*unable* to provide one or more `path` objects. Or any other ancillary data
that is known to the function that returned `expected<T, error_code>`.
The only thing you could throw from just an `error_code` is a
std::system_error.
It all comes back to the same issue: the needs for local error handling vs.
non-local. A mechanism that is good for one will *necessarily* not be good
for the other. Either local error handling gets more data and overhead than
they need, or non-local error handling gets less data.
In most cases, it is the caller who decides if he wants local or non-local
handling. So the filesystem TS's way of having two APIs is *correct*; it
allows each kind of error handler to work in the way that is best for them
(minus the whole "output by reference" thing). Nobody gets overhead that
they don't need, and everyone is happy.
Why change that? Just because you don't like seeing two functions in an
interface instead of one?
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_11516_1691810947.1447438120368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=C2=A0<iframe style=3D"padding: 0px; position: absolute; top: 0px; left: 0p=
x; width: 723px; height: 188px; visibility: hidden;" frameborder=3D"0"></if=
rame><br>On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero D=
eretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Hi Tony,<br><br>I strongly agree with most of what you wrote. Just wanted t=
o add a couple of comments.<br><br>On Thursday, November 12, 2015 at 8:35:0=
6 PM UTC, Tony V E wrote:<br><div></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><br></div>So, obvious=
ly, you are getting lots of different opinions from different people.<br></=
div><div>For example, Nevin mentioned that he doesn't like basic_string=
+ traits because no one really uses the traits.<br></div><div>Other people=
want/expect that if E is an exception_ptr, it should rethrow it, not throw=
bad_expected_access<exception_<wbr>ptr>.<br></div><div>Some people w=
ant it to be consistent, always throw bad_expected_access.<br></div><div>So=
me people want to avoid exceptions.<br>Etc.<br><br></div><div>And this is h=
ow the committee works.=C2=A0 Or fails to work, sometimes.<br><br></div><di=
v>So you think "allow customization - that will make everyone happy&qu=
ot;.=C2=A0 But even that doesn't, because then those who want simplicit=
y are not happy.<br><br></div><div>We need to look at each facet/opinion ca=
refully.=C2=A0 For example, in general I agree with Nevin - basically the c=
ommittee tends to over-customize when the average user doesn't want/nee=
d it.=C2=A0 But is that the case here?=C2=A0 Instead of saying "OK I w=
on't do traits", maybe you should say "here's how expecte=
d<> is different than basic_string...."=C2=A0 ie even if we tend=
to over-customize, maybe this is a case where customization is useful. Or =
maybe not.<br><br></div><div>So how to decide that?<br><br></div><div>I thi=
nk we first look at those wanting to avoid exceptions.=C2=A0 So they will u=
se expected<T, MyErrorCode> probably equivalent to expected<T, int=
>. Or similar.<br></div><div>OK. Did they avoid exceptions? Well, almost=
, but not really.=C2=A0 If they call ex.value() without checking, they may =
still get a bad_expected_access<int> exception.=C2=A0 But note - only=
if they call it.=C2=A0 And I suspect it would be easy for an implementatio=
n to just make that UB when/if the developer shuts off exceptions in their =
compiler.<br><br></div><div>So, 1. we don't need to define expected.val=
ue() to have undefined behaviour - it WILL throw.=C2=A0 The only question i=
s what it throws.=C2=A0 So let's not talk about IF it throws. Yes it do=
es.<br><br></div></div></blockquote><div><br>I'm also strongly in favor=
with ::value throwing an exception.<br></div></div></blockquote><div><br>G=
enerally speaking, nobody is opposed to `value` throwing. Even the one pers=
on who didn't like it said that it was fine due to consistency with sim=
ilar interfaces.<br><br>The question is what it throws. Should it throw a s=
ingle thing consistently for all `E`, or should it have special cases? And =
if it should have special cases, should they be customizable? And how do we=
customize them?<br><br>Behind all of these is the most important of all: w=
hat the <i>purpose</i> of this function not throwing a consistent type?<br>=
<br>Thus far, the main reason people give for wanting `value` to throw arbi=
trary things is to be able to merge non-local error interfaces with local e=
rror interfaces. So if the caller wants to catch the exception, they say `.=
value()` and just catch it wherever. If they do not, then the user uses ope=
rator* or otherwise manually test it.<br><br>My feeling is that any such me=
rger will hurt one kind of error handling or the other. And thus, while the=
idea of merging is well-intensioned, it just leads to too many problems.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></d=
iv><div>Magic: expected could just "do the right thing".=C2=A0 ie=
if E is exception_ptr, then rethrow it.=C2=A0 if E is derived from excepti=
on, throw it.=C2=A0 otherwise throw bad_expected_access<E>.<br><br></=
div><div>Always Throw E.=C2=A0 Simple.=C2=A0 But then you get a bunch of in=
ts being thrown.=C2=A0 I think this is a no-go option.<br><br></div><div>Al=
ways Throw bad_expected_access<E>.=C2=A0 Simple.=C2=A0 Possibly unexp=
ected.=C2=A0 And doesn't "unify" APIs like FileSystem.<br><br=
></div><div>Templatized: customize via a traits class *passed in* (which co=
uld default to magic or whatever).=C2=A0 APIs like FileSystem can turns int=
errors into exceptions *at the point when expected.value() is called*.=C2=
=A0 (The "wrap E with as_error/as_exception" idea would also go h=
ere under "Templatized".)<br></div><div><br><br>NOTE: for FileSys=
tem, the Magic option means, to unify its APIs, it would need to=20
use exception_ptr (or maybe some E derived from std::exception), so that th=
e "right" FileSystem exception is thrown.=C2=A0=20
This is bad for users that want to use FileSystem but avoid exceptions.<br>=
<br></div></div></blockquote><div><br>This I do not understand why would yo=
u need exception_ptr?</div></div></blockquote><div><br>What Tony (and appar=
ently yourself) want is to have APIs provide single functions that don'=
t throw. And therefore, any throwing of exceptions is based on how the call=
er uses the `expected` return value. So instead of having a `filesystem::fi=
le_size` function with two overloads, you just have one that returns an `ex=
pected<size_t, E>`<br><br>The question is what `E` should be.<br><br>=
Right now, `filesystem_error` provides rich information about why the error=
happened. Information that is useful to users who catch the exception, pos=
sibly far from the throwing location. So if you want to merge the interface=
s without the exception users losing information, you must return an `expec=
ted<T, exception_ptr>`. Or at the very least, `expected<T, filesys=
tem_error>`.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div>Either only use error codes or, better return an exp=
ected<T, std::variant<E1, E2...> >. In fact expected should hav=
e first class support for variant. <br>=C2=A0</div></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>----<br><br></div><div>Conclus=
ions?<br></div><div>1. If we find we need customization, I don't think =
it can be external (too many int errors), it needs to be part of the templa=
te.<br></div></div></blockquote><div><br>I strongly believe that expected s=
hould discourage int errors.<br></div></div></blockquote><div><br>"str=
ongly discouraging" things will not stop them from happening. `expecte=
d` should work with the reality we have, not the one we'd prefer.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><=
div>2. I don't think I like exception_ptr.=C2=A0 It doesn't help an=
API like FileSystem that is trying to avoid exceptions.=C2=A0 I'd pref=
er a trait-based customization, or throw E when E is derived from std::exce=
ption - because you can use std::exception without using exceptions. Can yo=
u give me more uses for expected<T, exception_ptr>?<br></div><div><br=
></div></div></blockquote><div><br>an std::rethrow could map error codes to=
exception hierarchies.<br></div></div></blockquote><div><br>OK, let's =
say we have some customization scheme that would convert `error_code` to an=
exception.<br><br>Look at `<a href=3D"http://en.cppreference.com/w/cpp/exp=
erimental/fs/filesystem_error">filesystem_error</a>`. It has 2 path objects=
; these exists so that users catching the exception can actually tell what =
caused the exception. After all, the location of the catch can be very dist=
ant from the immediate caller, so any paths passed to the throwing function=
may have long since been destroyed. Storing the path(s) that caused the er=
ror makes sense; it provides the catcher with vital and useful information.=
<br><br>`std::error_code` has no such information. So whatever customizatio=
n scheme you might envision to convert `error_code` into an exception would=
be <i>unable</i> to provide one or more `path` objects. Or any other ancil=
lary data that is known to the function that returned `expected<T, error=
_code>`.<br><br>The only thing you could throw from just an `error_code`=
is a std::system_error.<br><br>It all comes back to the same issue: the ne=
eds for local error handling vs. non-local. A mechanism that is good for on=
e will <i>necessarily</i> not be good for the other. Either local error han=
dling gets more data and overhead than they need, or non-local error handli=
ng gets less data.<br><br>In most cases, it is the caller who decides if he=
wants local or non-local handling. So the filesystem TS's way of havin=
g two APIs is <i>correct</i>; it allows each kind of error handler to work =
in the way that is best for them (minus the whole "output by reference=
" thing). Nobody gets overhead that they don't need, and everyone =
is happy.<br><br>Why change that? Just because you don't like seeing tw=
o functions in an interface instead of one?<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"></div></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_11516_1691810947.1447438120368--
------=_Part_11515_827818036.1447438120368--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 13 Nov 2015 13:28:41 -0500
Raw View
On 2015-11-13 13:08, Nicol Bolas wrote:
> In most cases, it is the caller who decides if he wants local or non-local
> handling. So the filesystem TS's way of having two APIs is *correct*; it
> allows each kind of error handler to work in the way that is best for them
> (minus the whole "output by reference" thing). Nobody gets overhead that
> they don't need, and everyone is happy.
>
> Why change that? Just because you don't like seeing two functions in an
> interface instead of one?
<Devil's Advocate>
Yes... that's twice as much API to build, document and maintain. And teach.
</Devil's Advocate>
I was one of the ones that originally wanted to see expected kill of the
dual-API of e.g. FS. At this point, however, I'm somewhat convinced of
the value (although personally I'd love to see just the expected version
and hang the exceptions ;-) ), but it's something to keep in mind that
others are going to take that view.
If it's possible to implement the throwing versions as lightweight
wrappers over the expected versions - and I think it should be - that
would probably help.
(Incidentally, it would probably also be nice if both sets have the same
signatures but live in different namespaces, e.g. std::fs::throwing and
std::fs::expect. Once expected kills the error code as an out parameter,
separating them by overrides is going to be harder and more awkward.)
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Nov 2015 10:56:52 -0800 (PST)
Raw View
------=_Part_657_179747409.1447441012482
Content-Type: multipart/alternative;
boundary="----=_Part_658_1281247075.1447441012482"
------=_Part_658_1281247075.1447441012482
Content-Type: text/plain; charset=UTF-8
On Friday, November 13, 2015 at 1:28:58 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-13 13:08, Nicol Bolas wrote:
> > In most cases, it is the caller who decides if he wants local or
> non-local
> > handling. So the filesystem TS's way of having two APIs is *correct*; it
> > allows each kind of error handler to work in the way that is best for
> them
> > (minus the whole "output by reference" thing). Nobody gets overhead that
> > they don't need, and everyone is happy.
> >
> > Why change that? Just because you don't like seeing two functions in an
> > interface instead of one?
>
> <Devil's Advocate>
>
> Yes... that's twice as much API to build, document and maintain. And teach.
>
Well, I wouldn't say twice as much to *teach*, since teaching is pretty
trivial. The cppreference site puts them both on the same page, so teaching
and documenting isn't hard.
The concern about building and maintaining is entirely valid. Even so, the
alternative is to give preference to one error method over the other. In
some cases, that makes sense. I can't say I see a great need for throwing
versions of stoi and so forth (`expected` would be the preferred way to go).
But as a general rule, I say let the user decide by calling a different
function.
>
> </Devil's Advocate>
>
> I was one of the ones that originally wanted to see expected kill of the
> dual-API of e.g. FS. At this point, however, I'm somewhat convinced of
> the value (although personally I'd love to see just the expected version
> and hang the exceptions ;-) ), but it's something to keep in mind that
> others are going to take that view.
>
> If it's possible to implement the throwing versions as lightweight
> wrappers over the expected versions - and I think it should be - that
> would probably help.
>
>
> (Incidentally, it would probably also be nice if both sets have the same
> signatures but live in different namespaces, e.g. std::fs::throwing and
> std::fs::expect. Once expected kills the error code as an out parameter,
> separating them by overrides is going to be harder and more awkward.)
>
That sounds even harder to teach, since not all functions can give rise to
errors. So you'd have functions in `std::fs`, `std::fs::throwing` and
`std::fs::expect`.
I'd much rather they be overloads, designated by some common tag that many
different libraries can use:
auto val = fs::file_size(p);
auto exp_val = fs::file_size(expect, p);
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_658_1281247075.1447441012482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, November 13, 2015 at 1:28:58 PM UTC-5, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-=
11-13 13:08, Nicol Bolas wrote:
<br>> In most cases, it is the caller who decides if he wants local or n=
on-local=20
<br>> handling. So the filesystem TS's way of having two APIs is *co=
rrect*; it=20
<br>> allows each kind of error handler to work in the way that is best =
for them=20
<br>> (minus the whole "output by reference" thing). Nobody ge=
ts overhead that=20
<br>> they don't need, and everyone is happy.
<br>>=20
<br>> Why change that? Just because you don't like seeing two functi=
ons in an=20
<br>> interface instead of one?
<br>
<br><Devil's Advocate>
<br>
<br>Yes... that's twice as much API to build, document and maintain. An=
d teach.<br></blockquote><div><br>Well, I wouldn't say twice as much to=
<i>teach</i>, since teaching is pretty trivial. The cppreference site puts=
them both on the same page, so teaching and documenting isn't hard.<br=
><br>The concern about building and maintaining is entirely valid. Even so,=
the alternative is to give preference to one error method over the other. =
In some cases, that makes sense. I can't say I see a great need for thr=
owing versions of stoi and so forth (`expected` would be the preferred way =
to go).<br><br>But as a general rule, I say let the user decide by calling =
a different function.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">
<br></Devil's Advocate>
<br>
<br>I was one of the ones that originally wanted to see expected kill of th=
e
<br>dual-API of e.g. FS. At this point, however, I'm somewhat convinced=
of
<br>the value (although personally I'd love to see just the expected ve=
rsion
<br>and hang the exceptions ;-) ), but it's something to keep in mind t=
hat
<br>others are going to take that view.
<br>
<br>If it's possible to implement the throwing versions as lightweight
<br>wrappers over the expected versions - and I think it should be - that
<br>would probably help.
<br>
<br></blockquote><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">(Incidentally, it would probably also be nice if both sets have the=
same
<br>signatures but live in different namespaces, e.g. std::fs::throwing and
<br>std::fs::expect. Once expected kills the error code as an out parameter=
,
<br>separating them by overrides is going to be harder and more awkward.)
<br></blockquote><div><br>That sounds even harder to teach, since not all f=
unctions can give rise to errors. So you'd have functions in `std::fs`,=
`std::fs::throwing` and `std::fs::expect`.</div><br>I'd much rather th=
ey be overloads, designated by some common tag that many different librarie=
s can use:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
val </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fs</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">file_size</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">p</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> exp_val </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> fs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">file_size</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">expect</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">);</span></div></code></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_658_1281247075.1447441012482--
------=_Part_657_179747409.1447441012482--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 13 Nov 2015 20:07:33 +0100
Raw View
This is a multi-part message in MIME format.
--------------010205040908090807000903
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 13/11/2015 19:08, Nicol Bolas a =C3=A9crit :
> =20
> On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero Deretta
> wrote:
>> Hi Tony,
>>
>> I strongly agree with most of what you wrote. Just wanted to add a coupl=
e
>> of comments.
>>
>> On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
>>
>>> So, obviously, you are getting lots of different opinions from differen=
t
>>> people.
>>> For example, Nevin mentioned that he doesn't like basic_string + traits
>>> because no one really uses the traits.
>>> Other people want/expect that if E is an exception_ptr, it should rethr=
ow
>>> it, not throw bad_expected_access<exception_ptr>.
>>> Some people want it to be consistent, always throw bad_expected_access.
>>> Some people want to avoid exceptions.
>>> Etc.
>>>
>>> And this is how the committee works. Or fails to work, sometimes.
>>>
>>> So you think "allow customization - that will make everyone happy". Bu=
t
>>> even that doesn't, because then those who want simplicity are not happy=
..
>>>
>>> We need to look at each facet/opinion carefully. For example, in gener=
al
>>> I agree with Nevin - basically the committee tends to over-customize wh=
en
>>> the average user doesn't want/need it. But is that the case here? Ins=
tead
>>> of saying "OK I won't do traits", maybe you should say "here's how
>>> expected<> is different than basic_string...." ie even if we tend to
>>> over-customize, maybe this is a case where customization is useful. Or
>>> maybe not.
>>>
>>> So how to decide that?
>>>
>>> I think we first look at those wanting to avoid exceptions. So they wi=
ll
>>> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. O=
r
>>> similar.
>>> OK. Did they avoid exceptions? Well, almost, but not really. If they
>>> call ex.value() without checking, they may still get a
>>> bad_expected_access<int> exception. But note - only if they call it. =
And
>>> I suspect it would be easy for an implementation to just make that UB
>>> when/if the developer shuts off exceptions in their compiler.
>>>
>>> So, 1. we don't need to define expected.value() to have undefined
>>> behaviour - it WILL throw. The only question is what it throws. So le=
t's
>>> not talk about IF it throws. Yes it does.
>>>
>>>
>> I'm also strongly in favor with ::value throwing an exception.
>>
> Generally speaking, nobody is opposed to `value` throwing. Even the one
> person who didn't like it said that it was fine due to consistency with
> similar interfaces.
>
> The question is what it throws. Should it throw a single thing consistent=
ly
> for all `E`, or should it have special cases? And if it should have speci=
al
> cases, should they be customizable? And how do we customize them?
>
> Behind all of these is the most important of all: what the *purpose* of
> this function not throwing a consistent type?
E.g. if I have expected<T, variant<E1, ..., En>> I would like to throw=20
Ei instead of variant<E1, ..., En>.
If I have expected<T,exception_ptr> the rethrow the stored exception.
If I have error_code throw system_error.
.....
> Thus far, the main reason people give for wanting `value` to throw
> arbitrary things is to be able to merge non-local error interfaces with
> local error interfaces. So if the caller wants to catch the exception, th=
ey
> say `.value()` and just catch it wherever. If they do not, then the user
> uses operator* or otherwise manually test it.
>
> My feeling is that any such merger will hurt one kind of error handling o=
r
> the other. And thus, while the idea of merging is well-intensioned, it ju=
st
> leads to too many problems.
The user is already able to implement whatever he wants with operator=20
bool(), operator*() and error().
We have two alternatives,
* don't provide value() at all or
* provide value() throwing the exception with less surprises. E=20
seems to be a first candidate, but it is surprising in some cases, thus=20
the need to customizing it.
* provide several non-member functions with different approaches
- value_or_throw<Exception>(e); // Exception must be=20
constructible from error(). Throws Exception when there is no value.
- value_or_throw<Thrower>(e); // throws the exception defined=20
by Thrower depending on the value error() when there is no value.
I like the last one. Instead of customizing the error once for all the=20
user can choose its own customizer.
>
> Magic: expected could just "do the right thing". ie if E is exception_pt=
r,
>>> then rethrow it. if E is derived from exception, throw it. otherwise
>>> throw bad_expected_access<E>.
>>>
>>> Always Throw E. Simple. But then you get a bunch of ints being thrown=
..
>>> I think this is a no-go option.
>>>
>>> Always Throw bad_expected_access<E>. Simple. Possibly unexpected. An=
d
>>> doesn't "unify" APIs like FileSystem.
>>>
>>> Templatized: customize via a traits class *passed in* (which could
>>> default to magic or whatever). APIs like FileSystem can turns int erro=
rs
>>> into exceptions *at the point when expected.value() is called*. (The "=
wrap
>>> E with as_error/as_exception" idea would also go here under "Templatize=
d".)
>>>
>>>
>>> NOTE: for FileSystem, the Magic option means, to unify its APIs, it wou=
ld
>>> need to use exception_ptr (or maybe some E derived from std::exception)=
, so
>>> that the "right" FileSystem exception is thrown. This is bad for users
>>> that want to use FileSystem but avoid exceptions.
>>>
>>>
>> This I do not understand why would you need exception_ptr?
>>
> What Tony (and apparently yourself) want is to have APIs provide single
> functions that don't throw. And therefore, any throwing of exceptions is
> based on how the caller uses the `expected` return value. So instead of
> having a `filesystem::file_size` function with two overloads, you just ha=
ve
> one that returns an `expected<size_t, E>`
>
> The question is what `E` should be.
>
> Right now, `filesystem_error` provides rich information about why the err=
or
> happened. Information that is useful to users who catch the exception,
> possibly far from the throwing location. So if you want to merge the
> interfaces without the exception users losing information, you must retur=
n
> an `expected<T, exception_ptr>`. Or at the very least, `expected<T,
> filesystem_error>`.
> =20
Or expected<T,E>, where E is a template parameter of the function. See=20
below.
>> Either only use error codes or, better return an expected<T,
>> std::variant<E1, E2...> >. In fact expected should have first class supp=
ort
>> for variant.
>> =20
>>
> ----
>>> Conclusions?
>>> 1. If we find we need customization, I don't think it can be external
>>> (too many int errors), it needs to be part of the template.
>>>
>> I strongly believe that expected should discourage int errors.
>>
> "strongly discouraging" things will not stop them from happening.
> `expected` should work with the reality we have, not the one we'd prefer.
If we have an external customization point that transform the error in=20
an exception, we discourage the use of buil-in types as we can have only=20
one mapping. This doesn't mean that the user can not use=20
expected<T,int>, just that it can not have a specific exception.
>
> 2. I don't think I like exception_ptr. It doesn't help an API like
>>> FileSystem that is trying to avoid exceptions. I'd prefer a trait-base=
d
>>> customization, or throw E when E is derived from std::exception - becau=
se
>>> you can use std::exception without using exceptions. Can you give me mo=
re
>>> uses for expected<T, exception_ptr>?
>>>
>>>
>> an std::rethrow could map error codes to exception hierarchies.
>>
> OK, let's say we have some customization scheme that would convert
> `error_code` to an exception.
>
> Look at `filesystem_error
> <http://en.cppreference.com/w/cpp/experimental/fs/filesystem_error>`. It
> has 2 path objects; these exists so that users catching the exception can
> actually tell what caused the exception. After all, the location of the
> catch can be very distant from the immediate caller, so any paths passed =
to
> the throwing function may have long since been destroyed. Storing the
> path(s) that caused the error makes sense; it provides the catcher with
> vital and useful information.
>
> `std::error_code` has no such information. So whatever customization sche=
me
> you might envision to convert `error_code` into an exception would be
> *unable* to provide one or more `path` objects. Or any other ancillary da=
ta
> that is known to the function that returned `expected<T, error_code>`.
>
> The only thing you could throw from just an `error_code` is a
> std::system_error.
>
> It all comes back to the same issue: the needs for local error handling v=
s.
> non-local. A mechanism that is good for one will *necessarily* not be goo=
d
> for the other. Either local error handling gets more data and overhead th=
an
> they need, or non-local error handling gets less data.
>
> In most cases, it is the caller who decides if he wants local or non-loca=
l
> handling. So the filesystem TS's way of having two APIs is *correct*; it
> allows each kind of error handler to work in the way that is best for the=
m
> (minus the whole "output by reference" thing). Nobody gets overhead that
> they don't need, and everyone is happy.
>
> Why change that? Just because you don't like seeing two functions in an
> interface instead of one?
>
If we want to manage local and remote error handling with different kind=20
of informations, I don't see another way than parameterizing the error=20
condition.
I have not think a lot about it but we could add such error condition=20
parameter EC as a template parameter
expected<size_t, EC> fsize =3D fs::file_size<EC>(p);
Now the user can decide the kind of error mechanism he needs.
This has a clear downside, it would transform almost the whole=20
implementation into templates.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------010205040908090807000903
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 13/11/2015 19:08, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:c313a803-b66f-42f2-9166-c44a5604e6be@isocpp.org"
type=3D"cite">
<pre wrap=3D"">=20
On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero Deretta=20
wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
Hi Tony,
I strongly agree with most of what you wrote. Just wanted to add a couple=
=20
of comments.
On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
So, obviously, you are getting lots of different opinions from different=20
people.
For example, Nevin mentioned that he doesn't like basic_string + traits=20
because no one really uses the traits.
Other people want/expect that if E is an exception_ptr, it should rethrow=
=20
it, not throw bad_expected_access<exception_ptr>.
Some people want it to be consistent, always throw bad_expected_access.
Some people want to avoid exceptions.
Etc.
And this is how the committee works. Or fails to work, sometimes.
So you think "allow customization - that will make everyone happy". But=20
even that doesn't, because then those who want simplicity are not happy.
We need to look at each facet/opinion carefully. For example, in general=
=20
I agree with Nevin - basically the committee tends to over-customize when=
=20
the average user doesn't want/need it. But is that the case here? Instead=
=20
of saying "OK I won't do traits", maybe you should say "here's how=20
expected<> is different than basic_string...." ie even if we tend to=
=20
over-customize, maybe this is a case where customization is useful. Or=20
maybe not.
So how to decide that?
I think we first look at those wanting to avoid exceptions. So they will=
=20
use expected<T, MyErrorCode> probably equivalent to expected<T, in=
t>. Or=20
similar.
OK. Did they avoid exceptions? Well, almost, but not really. If they=20
call ex.value() without checking, they may still get a=20
bad_expected_access<int> exception. But note - only if they call it.=
And=20
I suspect it would be easy for an implementation to just make that UB=20
when/if the developer shuts off exceptions in their compiler.
So, 1. we don't need to define expected.value() to have undefined=20
behaviour - it WILL throw. The only question is what it throws. So let's=
=20
not talk about IF it throws. Yes it does.
</pre>
</blockquote>
<pre wrap=3D"">I'm also strongly in favor with ::value throwing an =
exception.
</pre>
</blockquote>
<pre wrap=3D"">
Generally speaking, nobody is opposed to `value` throwing. Even the one=20
person who didn't like it said that it was fine due to consistency with=20
similar interfaces.
The question is what it throws. Should it throw a single thing consistently=
=20
for all `E`, or should it have special cases? And if it should have special=
=20
cases, should they be customizable? And how do we customize them?
Behind all of these is the most important of all: what the *purpose* of=20
this function not throwing a consistent type?
</pre>
</blockquote>
E.g. if I have expected<T, variant<E1, ..., En>> I would
like to throw Ei instead of variant<E1, ..., En>.<br>
If I have expected<T,exception_ptr> the rethrow the stored
exception.<br>
If I have error_code throw system_error.<br>
....<br>
<br>
<blockquote
cite=3D"mid:c313a803-b66f-42f2-9166-c44a5604e6be@isocpp.org"
type=3D"cite">
<pre wrap=3D"">
Thus far, the main reason people give for wanting `value` to throw=20
arbitrary things is to be able to merge non-local error interfaces with=20
local error interfaces. So if the caller wants to catch the exception, they=
=20
say `.value()` and just catch it wherever. If they do not, then the user=20
uses operator* or otherwise manually test it.
My feeling is that any such merger will hurt one kind of error handling or=
=20
the other. And thus, while the idea of merging is well-intensioned, it just=
=20
leads to too many problems.</pre>
</blockquote>
The user is already able to implement whatever he wants with
operator bool(), operator*() and error().<br>
We have two alternatives, <br>
=C2=A0=C2=A0=C2=A0 * don't provide value() at all or<br>
=C2=A0=C2=A0=C2=A0 * provide value() throwing the exception with less s=
urprises. E
seems to be a first candidate, but it is surprising in some cases,
thus the need to customizing it.<br>
=C2=A0=C2=A0=C2=A0 * provide several non-member functions with differen=
t approaches<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - value_or_throw<Exception>=
(e); // Exception must be
constructible from error(). Throws Exception when there is no value.<br=
>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - value_or_throw<Thrower>(e=
); // throws the exception
defined by Thrower depending on the value error() when there is no
value.<br>
<br>
I like the last one. Instead of customizing the error once for all
the user can choose its own customizer.<br>
<br>
<blockquote
cite=3D"mid:c313a803-b66f-42f2-9166-c44a5604e6be@isocpp.org"
type=3D"cite">
<pre wrap=3D"">
Magic: expected could just "do the right thing". ie if E is exception_ptr,=
=20
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">then rethrow it. if E is derived from exception, =
throw it. otherwise=20
throw bad_expected_access<E>.
Always Throw E. Simple. But then you get a bunch of ints being thrown. =
=20
I think this is a no-go option.
Always Throw bad_expected_access<E>. Simple. Possibly unexpected. =
And=20
doesn't "unify" APIs like FileSystem.
Templatized: customize via a traits class *passed in* (which could=20
default to magic or whatever). APIs like FileSystem can turns int errors=
=20
into exceptions *at the point when expected.value() is called*. (The "wrap=
=20
E with as_error/as_exception" idea would also go here under "Templatized".)
NOTE: for FileSystem, the Magic option means, to unify its APIs, it would=
=20
need to use exception_ptr (or maybe some E derived from std::exception), so=
=20
that the "right" FileSystem exception is thrown. This is bad for users=20
that want to use FileSystem but avoid exceptions.
</pre>
</blockquote>
<pre wrap=3D"">This I do not understand why would you need exceptio=
n_ptr?
</pre>
</blockquote>
<pre wrap=3D"">
What Tony (and apparently yourself) want is to have APIs provide single=20
functions that don't throw. And therefore, any throwing of exceptions is=20
based on how the caller uses the `expected` return value. So instead of=20
having a `filesystem::file_size` function with two overloads, you just have=
=20
one that returns an `expected<size_t, E>`
The question is what `E` should be.
Right now, `filesystem_error` provides rich information about why the error=
=20
happened. Information that is useful to users who catch the exception,=20
possibly far from the throwing location. So if you want to merge the=20
interfaces without the exception users losing information, you must return=
=20
an `expected<T, exception_ptr>`. Or at the very least, `expected<T=
,=20
filesystem_error>`.
=20
</pre>
</blockquote>
Or expected<T,E>, where E is a template parameter of the
function. See below.<br>
<blockquote
cite=3D"mid:c313a803-b66f-42f2-9166-c44a5604e6be@isocpp.org"
type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Either only use error codes or, better return an exp=
ected<T,=20
std::variant<E1, E2...> >. In fact expected should have first clas=
s support=20
for variant.=20
=20
</pre>
</blockquote>
<pre wrap=3D"">----
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">
Conclusions?
1. If we find we need customization, I don't think it can be external=20
(too many int errors), it needs to be part of the template.
</pre>
</blockquote>
<pre wrap=3D"">
I strongly believe that expected should discourage int errors.
</pre>
</blockquote>
<pre wrap=3D"">
"strongly discouraging" things will not stop them from happening.=20
`expected` should work with the reality we have, not the one we'd prefer.</=
pre>
</blockquote>
If we have an external customization point that transform the error
in an exception, we discourage the use of buil-in types as we can
have only one mapping. This doesn't mean that the user can not use
expected<T,int>, just that it can not have a specific
exception.<br>
<blockquote
cite=3D"mid:c313a803-b66f-42f2-9166-c44a5604e6be@isocpp.org"
type=3D"cite">
<pre wrap=3D"">
2. I don't think I like exception_ptr. It doesn't help an API like=20
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">FileSystem that is trying to avoid exceptions. I'=
d prefer a trait-based=20
customization, or throw E when E is derived from std::exception - because=
=20
you can use std::exception without using exceptions. Can you give me more=
=20
uses for expected<T, exception_ptr>?
</pre>
</blockquote>
<pre wrap=3D"">an std::rethrow could map error codes to exception h=
ierarchies.
</pre>
</blockquote>
<pre wrap=3D"">
OK, let's say we have some customization scheme that would convert=20
`error_code` to an exception.
Look at `filesystem_error=20
<a class=3D"moz-txt-link-rfc2396E" href=3D"http://en.cppreference.com/w/cpp=
/experimental/fs/filesystem_error"><http://en.cppreference.com/w/cpp/exp=
erimental/fs/filesystem_error></a>`. It=20
has 2 path objects; these exists so that users catching the exception can=
=20
actually tell what caused the exception. After all, the location of the=20
catch can be very distant from the immediate caller, so any paths passed to=
=20
the throwing function may have long since been destroyed. Storing the=20
path(s) that caused the error makes sense; it provides the catcher with=20
vital and useful information.
`std::error_code` has no such information. So whatever customization scheme=
=20
you might envision to convert `error_code` into an exception would be=20
*unable* to provide one or more `path` objects. Or any other ancillary data=
=20
that is known to the function that returned `expected<T, error_code>`=
..
The only thing you could throw from just an `error_code` is a=20
std::system_error.
It all comes back to the same issue: the needs for local error handling vs.=
=20
non-local. A mechanism that is good for one will *necessarily* not be good=
=20
for the other. Either local error handling gets more data and overhead than=
=20
they need, or non-local error handling gets less data.
In most cases, it is the caller who decides if he wants local or non-local=
=20
handling. So the filesystem TS's way of having two APIs is *correct*; it=20
allows each kind of error handler to work in the way that is best for them=
=20
(minus the whole "output by reference" thing). Nobody gets overhead that=20
they don't need, and everyone is happy.
Why change that? Just because you don't like seeing two functions in an=20
interface instead of one?
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
</pre>
</blockquote>
<pre wrap=3D"">
</pre>
</blockquote>
<font size=3D"+1">If we want to manage local and remote error handling
with different kind of informations, I don't see another way than
parameterizing the error condition.<br>
<br>
I have not think a lot about it but we could add such error
condition parameter EC as a template parameter<br>
</font>
<pre wrap=3D"">
expected<size_t, EC> fsize =3D fs::file_size<EC>(p);</pre>
=C2=A0
<br>
Now the user can decide the kind of error mechanism he needs.<br>
<br>
This has a clear downside, it would transform almost the whole
implementation into templates.<br>
<br>
Vicente<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------010205040908090807000903--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Nov 2015 11:35:40 -0800 (PST)
Raw View
------=_Part_1227_907981714.1447443340481
Content-Type: multipart/alternative;
boundary="----=_Part_1228_1014987836.1447443340482"
------=_Part_1228_1014987836.1447443340482
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, November 13, 2015 at 2:07:36 PM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 13/11/2015 19:08, Nicol Bolas a =C3=A9crit :
>
> =20
> On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero Deretta=
=20
> wrote:
>
> Hi Tony,
>
> I strongly agree with most of what you wrote. Just wanted to add a couple=
=20
> of comments.
>
> On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
>
>
> So, obviously, you are getting lots of different opinions from different=
=20
> people.
> For example, Nevin mentioned that he doesn't like basic_string + traits=
=20
> because no one really uses the traits.
> Other people want/expect that if E is an exception_ptr, it should rethrow=
=20
> it, not throw bad_expected_access<exception_ptr>.
> Some people want it to be consistent, always throw bad_expected_access.
> Some people want to avoid exceptions.
> Etc.
>
> And this is how the committee works. Or fails to work, sometimes.
>
> So you think "allow customization - that will make everyone happy". But=
=20
> even that doesn't, because then those who want simplicity are not happy.
>
> We need to look at each facet/opinion carefully. For example, in general=
=20
> I agree with Nevin - basically the committee tends to over-customize when=
=20
> the average user doesn't want/need it. But is that the case here? Inste=
ad=20
> of saying "OK I won't do traits", maybe you should say "here's how=20
> expected<> is different than basic_string...." ie even if we tend to=20
> over-customize, maybe this is a case where customization is useful. Or=20
> maybe not.
>
> So how to decide that?
>
> I think we first look at those wanting to avoid exceptions. So they will=
=20
> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or=
=20
> similar.
> OK. Did they avoid exceptions? Well, almost, but not really. If they=20
> call ex.value() without checking, they may still get a=20
> bad_expected_access<int> exception. But note - only if they call it. An=
d=20
> I suspect it would be easy for an implementation to just make that UB=20
> when/if the developer shuts off exceptions in their compiler.
>
> So, 1. we don't need to define expected.value() to have undefined=20
> behaviour - it WILL throw. The only question is what it throws. So let'=
s=20
> not talk about IF it throws. Yes it does.
>
>
>
> I'm also strongly in favor with ::value throwing an exception.
>
>
> Generally speaking, nobody is opposed to `value` throwing. Even the one=
=20
> person who didn't like it said that it was fine due to consistency with=
=20
> similar interfaces.
>
> The question is what it throws. Should it throw a single thing consistent=
ly=20
> for all `E`, or should it have special cases? And if it should have speci=
al=20
> cases, should they be customizable? And how do we customize them?
>
> Behind all of these is the most important of all: what the *purpose* of=
=20
> this function not throwing a consistent type?
>
> E.g. if I have expected<T, variant<E1, ..., En>> I would like to throw Ei=
=20
> instead of variant<E1, ..., En>.
> If I have expected<T,exception_ptr> the rethrow the stored exception.
> If I have error_code throw system_error.
> ....
>
You did not answer my question. What *purpose* does it serve to be able to=
=20
do that. Yes, I understand that you want to throw `E1` if it's packaged in=
=20
a variant or rethrow the exception_ptr or whatever.
*Why do you want to do this?* What do you have to gain by it? How will=20
users actually use that to achieve something?
> Thus far, the main reason people give for wanting `value` to throw=20
> arbitrary things is to be able to merge non-local error interfaces with=
=20
> local error interfaces. So if the caller wants to catch the exception, th=
ey=20
> say `.value()` and just catch it wherever. If they do not, then the user=
=20
> uses operator* or otherwise manually test it.
>
> My feeling is that any such merger will hurt one kind of error handling o=
r=20
> the other. And thus, while the idea of merging is well-intensioned, it ju=
st=20
> leads to too many problems.
>
> The user is already able to implement whatever he wants with operator=20
> bool(), operator*() and error().
> We have two alternatives,=20
> * don't provide value() at all or
> * provide value() throwing the exception with less surprises. E seems=
=20
> to be a first candidate, but it is surprising in some cases, thus the nee=
d=20
> to customizing it.
> * provide several non-member functions with different approaches
> - value_or_throw<Exception>(e); // Exception must be constructibl=
e=20
> from error(). Throws Exception when there is no value.
> - value_or_throw<Thrower>(e); // throws the exception defined by=
=20
> Thrower depending on the value error() when there is no value.
>
> I like the last one. Instead of customizing the error once for all the=20
> user can choose its own customizer.
>
I don't know. It seems to me that if the direct user of this object cares=
=20
that much about exactly what exception is thrown when they ask for the=20
value... they don't really care much about getting the value. Or at the=20
very least, what you have is a statement that's trying to do too much. It's=
=20
trying to decide what exception to throw if it's an error, and it's getting=
=20
the value if it's not.
It makes much more sense for this to be two functions: `value` and=20
`throw_if_error<Customization>`. `value` would through the generic error,=
=20
while `throw_if_error` uses the customization to decide what to throw.
That way, users of `value` can treat an exception as a failure in their=20
code, as a logic error or precondition violation, rather than something=20
that they want to happen.
> Magic: expected could just "do the right thing". ie if E is exception_pt=
r,=20
>
> then rethrow it. if E is derived from exception, throw it. otherwise=20
> throw bad_expected_access<E>.
>
> Always Throw E. Simple. But then you get a bunch of ints being thrown. =
=20
> I think this is a no-go option.
>
> Always Throw bad_expected_access<E>. Simple. Possibly unexpected. And=
=20
> doesn't "unify" APIs like FileSystem.
>
> Templatized: customize via a traits class *passed in* (which could=20
> default to magic or whatever). APIs like FileSystem can turns int errors=
=20
> into exceptions *at the point when expected.value() is called*. (The "wr=
ap=20
> E with as_error/as_exception" idea would also go here under "Templatized"=
..)
>
>
> NOTE: for FileSystem, the Magic option means, to unify its APIs, it would=
=20
> need to use exception_ptr (or maybe some E derived from std::exception), =
so=20
> that the "right" FileSystem exception is thrown. This is bad for users=
=20
> that want to use FileSystem but avoid exceptions.
>
>
>
> This I do not understand why would you need exception_ptr?
>
>
> What Tony (and apparently yourself) want is to have APIs provide single=
=20
> functions that don't throw. And therefore, any throwing of exceptions is=
=20
> based on how the caller uses the `expected` return value. So instead of=
=20
> having a `filesystem::file_size` function with two overloads, you just ha=
ve=20
> one that returns an `expected<size_t, E>`
>
> The question is what `E` should be.
>
> Right now, `filesystem_error` provides rich information about why the err=
or=20
> happened. Information that is useful to users who catch the exception,=20
> possibly far from the throwing location. So if you want to merge the=20
> interfaces without the exception users losing information, you must retur=
n=20
> an `expected<T, exception_ptr>`. Or at the very least, `expected<T,=20
> filesystem_error>`.
> =20
>
> Or expected<T,E>, where E is a template parameter of the function. See=20
> below.
>
> Either only use error codes or, better return an expected<T,=20
> std::variant<E1, E2...> >. In fact expected should have first class suppo=
rt=20
> for variant.=20
> =20
>
>
> ----
>
> Conclusions?
> 1. If we find we need customization, I don't think it can be external=20
> (too many int errors), it needs to be part of the template.
>
>
> I strongly believe that expected should discourage int errors.
>
>
> "strongly discouraging" things will not stop them from happening.=20
> `expected` should work with the reality we have, not the one we'd prefer.
>
> If we have an external customization point that transform the error in an=
=20
> exception, we discourage the use of buil-in types as we can have only one=
=20
> mapping. This doesn't mean that the user can not use expected<T,int>, jus=
t=20
> that it can not have a specific exception.
>
> 2. I don't think I like exception_ptr. It doesn't help an API like=20
>
> FileSystem that is trying to avoid exceptions. I'd prefer a trait-based=
=20
> customization, or throw E when E is derived from std::exception - because=
=20
> you can use std::exception without using exceptions. Can you give me more=
=20
> uses for expected<T, exception_ptr>?
>
>
>
> an std::rethrow could map error codes to exception hierarchies.
>
>
> OK, let's say we have some customization scheme that would convert=20
> `error_code` to an exception.
>
> Look at `filesystem_error <http://en.cppreference.com/w/cpp/experimental/=
fs/filesystem_error> <http://en.cppreference.com/w/cpp/experimental/fs/file=
system_error>`. It=20
> has 2 path objects; these exists so that users catching the exception can=
=20
> actually tell what caused the exception. After all, the location of the=
=20
> catch can be very distant from the immediate caller, so any paths passed =
to=20
> the throwing function may have long since been destroyed. Storing the=20
> path(s) that caused the error makes sense; it provides the catcher with=
=20
> vital and useful information.
>
> `std::error_code` has no such information. So whatever customization sche=
me=20
> you might envision to convert `error_code` into an exception would be=20
> *unable* to provide one or more `path` objects. Or any other ancillary da=
ta=20
> that is known to the function that returned `expected<T, error_code>`.
>
> The only thing you could throw from just an `error_code` is a=20
> std::system_error.
>
> It all comes back to the same issue: the needs for local error handling v=
s.=20
> non-local. A mechanism that is good for one will *necessarily* not be goo=
d=20
> for the other. Either local error handling gets more data and overhead th=
an=20
> they need, or non-local error handling gets less data.
>
> In most cases, it is the caller who decides if he wants local or non-loca=
l=20
> handling. So the filesystem TS's way of having two APIs is *correct*; it=
=20
> allows each kind of error handler to work in the way that is best for the=
m=20
> (minus the whole "output by reference" thing). Nobody gets overhead that=
=20
> they don't need, and everyone is happy.
>
> Why change that? Just because you don't like seeing two functions in an=
=20
> interface instead of one?
>
>
> If we want to manage local and remote error handling with different kind=
=20
> of informations, I don't see another way than parameterizing the error=20
> condition.
>
> I have not think a lot about it but we could add such error condition=20
> parameter EC as a template parameter
>
> expected<size_t, EC> fsize =3D fs::file_size<EC>(p);
>
> =20
> Now the user can decide the kind of error mechanism he needs.
>
Except that it doesn't. Or at least, it's not clear what `EC` means here.=
=20
Are these types that the FileSystem library would provide? Does the=20
FileSystem interface impose some concept on `EC`? Does it construct this=20
object with paths and other data, and let the type decide which data to=20
keep?
Furthermore, if you want a genuine exception, it's not clear how that would=
=20
work. An `EC` type could just throw in its constructor, building the=20
exception from the parameters. But the caller still gets an=20
`expected<size_t, EC>`. Even though it is functionally impossible to=20
construct an EC type (since it just throws), you still have to have your=20
code go through the `expected`.
Would the function have some specialization basedon on the EC type, where=
=20
if it has some property then the function returns `size_t` instead of=20
`expected<size_t, EC>`?
Ultimately, this all sounds like something that's really hard to teach.=20
Certainly much more difficult than a simple overload.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1228_1014987836.1447443340482
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, November 13, 2015 at 2:07:36 PM UTC-5, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 13/11/2015 19:08, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<pre>=20
On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero Deretta=20
wrote:
</pre>
<blockquote type=3D"cite">
<pre>Hi Tony,
I strongly agree with most of what you wrote. Just wanted to add a couple=
=20
of comments.
On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
</pre>
<blockquote type=3D"cite">
<pre>So, obviously, you are getting lots of different opinions fr=
om different=20
people.
For example, Nevin mentioned that he doesn't like basic_string + traits=
=20
because no one really uses the traits.
Other people want/expect that if E is an exception_ptr, it should rethrow=
=20
it, not throw bad_expected_access<exception_<wbr>ptr>.
Some people want it to be consistent, always throw bad_expected_access.
Some people want to avoid exceptions.
Etc.
And this is how the committee works. Or fails to work, sometimes.
So you think "allow customization - that will make everyone happy"=
;. But=20
even that doesn't, because then those who want simplicity are not happy=
..
We need to look at each facet/opinion carefully. For example, in general=
=20
I agree with Nevin - basically the committee tends to over-customize when=
=20
the average user doesn't want/need it. But is that the case here? Ins=
tead=20
of saying "OK I won't do traits", maybe you should say "=
here's how=20
expected<> is different than basic_string...." ie even if we te=
nd to=20
over-customize, maybe this is a case where customization is useful. Or=20
maybe not.
So how to decide that?
I think we first look at those wanting to avoid exceptions. So they will=
=20
use expected<T, MyErrorCode> probably equivalent to expected<T, in=
t>. Or=20
similar.
OK. Did they avoid exceptions? Well, almost, but not really. If they=20
call ex.value() without checking, they may still get a=20
bad_expected_access<int> exception. But note - only if they call it.=
And=20
I suspect it would be easy for an implementation to just make that UB=20
when/if the developer shuts off exceptions in their compiler.
So, 1. we don't need to define expected.value() to have undefined=20
behaviour - it WILL throw. The only question is what it throws. So let=
9;s=20
not talk about IF it throws. Yes it does.
</pre>
</blockquote>
<pre>I'm also strongly in favor with ::value throwing an except=
ion.
</pre>
</blockquote>
<pre>Generally speaking, nobody is opposed to `value` throwing. Even =
the one=20
person who didn't like it said that it was fine due to consistency with=
=20
similar interfaces.
The question is what it throws. Should it throw a single thing consistently=
=20
for all `E`, or should it have special cases? And if it should have special=
=20
cases, should they be customizable? And how do we customize them?
Behind all of these is the most important of all: what the *purpose* of=20
this function not throwing a consistent type?
</pre>
</blockquote>
E.g. if I have expected<T, variant<E1, ..., En>> I would
like to throw Ei instead of variant<E1, ..., En>.<br>
If I have expected<T,exception_ptr> the rethrow the stored
exception.<br>
If I have error_code throw system_error.<br>
....<br></div></blockquote><div><br>You did not answer my question. Wha=
t <i>purpose</i> does it serve to be able to do that. Yes, I understand tha=
t you want to throw `E1` if it's packaged in a variant or rethrow the e=
xception_ptr or whatever.<br><br><i>Why do you want to do this?</i> What do=
you have to gain by it? How will users actually use that to achieve someth=
ing?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
<br>
<blockquote type=3D"cite">
<pre>Thus far, the main reason people give for wanting `value` to thr=
ow=20
arbitrary things is to be able to merge non-local error interfaces with=20
local error interfaces. So if the caller wants to catch the exception, they=
=20
say `.value()` and just catch it wherever. If they do not, then the user=20
uses operator* or otherwise manually test it.
My feeling is that any such merger will hurt one kind of error handling or=
=20
the other. And thus, while the idea of merging is well-intensioned, it just=
=20
leads to too many problems.</pre>
</blockquote>
The user is already able to implement whatever he wants with
operator bool(), operator*() and error().<br>
We have two alternatives, <br>
=C2=A0=C2=A0=C2=A0 * don't provide value() at all or<br>
=C2=A0=C2=A0=C2=A0 * provide value() throwing the exception with less s=
urprises. E
seems to be a first candidate, but it is surprising in some cases,
thus the need to customizing it.<br>
=C2=A0=C2=A0=C2=A0 * provide several non-member functions with differen=
t approaches<br>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - value_or_throw<Exception>=
(e); // Exception must be
constructible from error(). Throws Exception when there is no value.<br=
>
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 - value_or_throw<Thrower>(e=
); // throws the exception
defined by Thrower depending on the value error() when there is no
value.<br>
<br>
I like the last one. Instead of customizing the error once for all
the user can choose its own customizer.<br></div></blockquote><div><br>=
I don't know. It seems to me that if the direct user of this object car=
es that much about exactly what exception is thrown when they ask for the v=
alue... they don't really care much about getting the value. Or at the =
very least, what you have is a statement that's trying to do too much. =
It's trying to decide what exception to throw if it's an error, and=
it's getting the value if it's not.<br><br>It makes much more sens=
e for this to be two functions: `value` and `throw_if_error<Customizatio=
n>`. `value` would through the generic error, while `throw_if_error` use=
s the customization to decide what to throw.<br><br>That way, users of `val=
ue` can treat an exception as a failure in their code, as a logic error or =
precondition violation, rather than something that they want to happen.<br>=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"=
#FFFFFF" text=3D"#000000">
<br>
<blockquote type=3D"cite">
<pre>Magic: expected could just "do the right thing". ie i=
f E is exception_ptr,=20
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre>then rethrow it. if E is derived from exception, throw it. =
otherwise=20
throw bad_expected_access<E>.
Always Throw E. Simple. But then you get a bunch of ints being thrown. =
=20
I think this is a no-go option.
Always Throw bad_expected_access<E>. Simple. Possibly unexpected. =
And=20
doesn't "unify" APIs like FileSystem.
Templatized: customize via a traits class *passed in* (which could=20
default to magic or whatever). APIs like FileSystem can turns int errors=
=20
into exceptions *at the point when expected.value() is called*. (The "=
;wrap=20
E with as_error/as_exception" idea would also go here under "Temp=
latized".)
NOTE: for FileSystem, the Magic option means, to unify its APIs, it would=
=20
need to use exception_ptr (or maybe some E derived from std::exception), so=
=20
that the "right" FileSystem exception is thrown. This is bad for=
users=20
that want to use FileSystem but avoid exceptions.
</pre>
</blockquote>
<pre>This I do not understand why would you need exception_ptr?
</pre>
</blockquote>
<pre>What Tony (and apparently yourself) want is to have APIs provide=
single=20
functions that don't throw. And therefore, any throwing of exceptions i=
s=20
based on how the caller uses the `expected` return value. So instead of=20
having a `filesystem::file_size` function with two overloads, you just have=
=20
one that returns an `expected<size_t, E>`
The question is what `E` should be.
Right now, `filesystem_error` provides rich information about why the error=
=20
happened. Information that is useful to users who catch the exception,=20
possibly far from the throwing location. So if you want to merge the=20
interfaces without the exception users losing information, you must return=
=20
an `expected<T, exception_ptr>`. Or at the very least, `expected<T=
,=20
filesystem_error>`.
=20
</pre>
</blockquote>
Or expected<T,E>, where E is a template parameter of the
function. See below.<br>
<blockquote type=3D"cite">
<pre></pre>
<blockquote type=3D"cite">
<pre>Either only use error codes or, better return an expected<T=
,=20
std::variant<E1, E2...> >. In fact expected should have first clas=
s support=20
for variant.=20
=20
</pre>
</blockquote>
<pre>----
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre>Conclusions?
1. If we find we need customization, I don't think it can be external=
=20
(too many int errors), it needs to be part of the template.
</pre>
</blockquote>
<pre>I strongly believe that expected should discourage int errors.
</pre>
</blockquote>
<pre>"strongly discouraging" things will not stop them from=
happening.=20
`expected` should work with the reality we have, not the one we'd prefe=
r.</pre>
</blockquote>
If we have an external customization point that transform the error
in an exception, we discourage the use of buil-in types as we can
have only one mapping. This doesn't mean that the user can not use
expected<T,int>, just that it can not have a specific
exception.<br>
<blockquote type=3D"cite">
<pre>2. I don't think I like exception_ptr. It doesn't help =
an API like=20
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre>FileSystem that is trying to avoid exceptions. I'd pref=
er a trait-based=20
customization, or throw E when E is derived from std::exception - because=
=20
you can use std::exception without using exceptions. Can you give me more=
=20
uses for expected<T, exception_ptr>?
</pre>
</blockquote>
<pre>an std::rethrow could map error codes to exception hierarchies=
..
</pre>
</blockquote>
<pre>OK, let's say we have some customization scheme that would c=
onvert=20
`error_code` to an exception.
Look at `filesystem_error=20
<a href=3D"http://en.cppreference.com/w/cpp/experimental/fs/filesystem_erro=
r" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fexper=
imental%2Ffs%2Ffilesystem_error\46sa\75D\46sntz\0751\46usg\75AFQjCNGf-ieuTu=
uIoXkUgvzk8jbz31_zHw';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fexperim=
ental%2Ffs%2Ffilesystem_error\46sa\75D\46sntz\0751\46usg\75AFQjCNGf-ieuTuuI=
oXkUgvzk8jbz31_zHw';return true;"><http://en.cppreference.com/w/<wbr=
>cpp/experimental/fs/<wbr>filesystem_error></a>`. It=20
has 2 path objects; these exists so that users catching the exception can=
=20
actually tell what caused the exception. After all, the location of the=20
catch can be very distant from the immediate caller, so any paths passed to=
=20
the throwing function may have long since been destroyed. Storing the=20
path(s) that caused the error makes sense; it provides the catcher with=20
vital and useful information.
`std::error_code` has no such information. So whatever customization scheme=
=20
you might envision to convert `error_code` into an exception would be=20
*unable* to provide one or more `path` objects. Or any other ancillary data=
=20
that is known to the function that returned `expected<T, error_code>`=
..
The only thing you could throw from just an `error_code` is a=20
std::system_error.
It all comes back to the same issue: the needs for local error handling vs.=
=20
non-local. A mechanism that is good for one will *necessarily* not be good=
=20
for the other. Either local error handling gets more data and overhead than=
=20
they need, or non-local error handling gets less data.
In most cases, it is the caller who decides if he wants local or non-local=
=20
handling. So the filesystem TS's way of having two APIs is *correct*; i=
t=20
allows each kind of error handler to work in the way that is best for them=
=20
(minus the whole "output by reference" thing). Nobody gets overhe=
ad that=20
they don't need, and everyone is happy.
Why change that? Just because you don't like seeing two functions in an=
=20
interface instead of one?
</pre>
<blockquote type=3D"cite">
<pre></pre>
</blockquote>
<pre></pre>
</blockquote>
<font size=3D"+1">If we want to manage local and remote error handling
with different kind of informations, I don't see another way than
parameterizing the error condition.<br>
<br>
I have not think a lot about it but we could add such error
condition parameter EC as a template parameter<br>
</font>
<pre> expected<size_t, EC> fsize =3D fs::file_size<EC>(p);<=
/pre>
=C2=A0
<br>
Now the user can decide the kind of error mechanism he needs.<br></div>=
</blockquote><div><br>Except that it doesn't. Or at least, it's not=
clear what `EC` means here. Are these types that the FileSystem library wo=
uld provide? Does the FileSystem interface impose some concept on `EC`? Doe=
s it construct this object with paths and other data, and let the type deci=
de which data to keep?<br><br>Furthermore, if you want a genuine exception,=
it's not clear how that would work. An `EC` type could just throw in i=
ts constructor, building the exception from the parameters. But the caller =
still gets an `expected<size_t, EC>`. Even though it is functionally =
impossible to construct an EC type (since it just throws), you still have t=
o have your code go through the `expected`.<br><br>Would the function have =
some specialization basedon on the EC type, where if it has some property t=
hen the function returns `size_t` instead of `expected<size_t, EC>`?<=
br><br>Ultimately, this all sounds like something that's really hard to=
teach. Certainly much more difficult than a simple overload.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1228_1014987836.1447443340482--
------=_Part_1227_907981714.1447443340481--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Fri, 13 Nov 2015 14:54:42 -0500
Raw View
On 2015-11-13 13:56, Nicol Bolas wrote:
> On Friday, November 13, 2015 at 1:28:58 PM UTC-5, Matthew Woehlke wrote:
>> (Incidentally, it would probably also be nice if both sets have the same
>> signatures but live in different namespaces, e.g. std::fs::throwing and
>> std::fs::expect. Once expected kills the error code as an out parameter,
>> separating them by overrides is going to be harder and more awkward.)
>
> That sounds even harder to teach, since not all functions can give rise to
> errors. So you'd have functions in `std::fs`, `std::fs::throwing` and
> `std::fs::expect`.
That's trivially fixed: have one-version functions in std::fs, and:
namespace std { namespace fs {
namespace throwing { using ::std::fs; }
namespace expected { using ::std::fs; }
} }
There; now it doesn't matter, just always use one of the throwing or
expected namespaces :-).
> I'd much rather they be overloads, designated by some common tag that many
> different libraries can use:
>
> auto val = fs::file_size(p);
> auto exp_val = fs::file_size(expect, p);
....but now one or the other camp has to type a bunch more. That's going
to lead to complaints of favoritism. (On which note, I hereby make such
complaint ;-).)
Using the two namespaces, it's trivial to just alias the one you want to
use and not worry about it 99% of the time.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Nov 2015 12:04:13 -0800 (PST)
Raw View
------=_Part_11757_443443123.1447445053223
Content-Type: multipart/alternative;
boundary="----=_Part_11758_125220492.1447445053224"
------=_Part_11758_125220492.1447445053224
Content-Type: text/plain; charset=UTF-8
On Friday, November 13, 2015 at 2:55:54 PM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-13 13:56, Nicol Bolas wrote:
> > On Friday, November 13, 2015 at 1:28:58 PM UTC-5, Matthew Woehlke wrote:
> >> (Incidentally, it would probably also be nice if both sets have the
> same
> >> signatures but live in different namespaces, e.g. std::fs::throwing and
> >> std::fs::expect. Once expected kills the error code as an out
> parameter,
> >> separating them by overrides is going to be harder and more awkward.)
> >
> > That sounds even harder to teach, since not all functions can give rise
> to
> > errors. So you'd have functions in `std::fs`, `std::fs::throwing` and
> > `std::fs::expect`.
>
> That's trivially fixed: have one-version functions in std::fs, and:
>
> namespace std { namespace fs {
> namespace throwing { using ::std::fs; }
> namespace expected { using ::std::fs; }
> } }
>
> There; now it doesn't matter, just always use one of the throwing or
> expected namespaces :-).
>
> > I'd much rather they be overloads, designated by some common tag that
> many
> > different libraries can use:
> >
> > auto val = fs::file_size(p);
> > auto exp_val = fs::file_size(expect, p);
>
> ...but now one or the other camp has to type a bunch more. That's going
> to lead to complaints of favoritism. (On which note, I hereby make such
> complaint ;-).)
>
> Using the two namespaces, it's trivial to just alias the one you want to
> use and not worry about it 99% of the time.
>
The thing is, the camps are not *that* separate. Outside of scenarios where
a project is forbidden from using exceptions, the question is generally one
of how you want to handle that particular error. If you were given a list
of files to iterate through and accumulate the sizes, if there's an error,
you want that to be an exception caught by the process that told you to do
it. But if you've been given a directory to iterate through (perhaps
calling the previous function), and the directory is not valid, you want to
handle that error condition locally.
Same code, different error behavior. This is the kind of coding that I
think we should encourage: not two distinct camps wishing the other one
didn't exist, but just people who use whatever error mechanism is most
appropriate at the time.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_11758_125220492.1447445053224
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Friday, November 13, 2015 at 2:55:54 PM UTC-5, Matthew Woehlke w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-13 13:56, Nico=
l Bolas wrote:
<br>> On Friday, November 13, 2015 at 1:28:58 PM UTC-5, Matthew Woehlke =
wrote:
<br>>> (Incidentally, it would probably also be nice if both sets hav=
e the same=20
<br>>> signatures but live in different namespaces, e.g. std::fs::thr=
owing and=20
<br>>> std::fs::expect. Once expected kills the error code as an out =
parameter,=20
<br>>> separating them by overrides is going to be harder and more aw=
kward.)=20
<br>>=20
<br>> That sounds even harder to teach, since not all functions can give=
rise to=20
<br>> errors. So you'd have functions in `std::fs`, `std::fs::throwi=
ng` and=20
<br>> `std::fs::expect`.
<br>
<br>That's trivially fixed: have one-version functions in std::fs, and:
<br>
<br>=C2=A0 namespace std { namespace fs {
<br>=C2=A0 =C2=A0 namespace throwing { using ::std::fs; }
<br>=C2=A0 =C2=A0 namespace expected { using ::std::fs; }
<br>=C2=A0 } }
<br>
<br>There; now it doesn't matter, just always use one of the throwing o=
r
<br>expected namespaces :-).
<br>
<br>> I'd much rather they be overloads, designated by some common t=
ag that many=20
<br>> different libraries can use:
<br>>=20
<br>> auto val =3D fs::file_size(p);
<br>> auto exp_val =3D fs::file_size(expect, p);
<br>
<br>...but now one or the other camp has to type a bunch more. That's g=
oing
<br>to lead to complaints of favoritism. (On which note, I hereby make such
<br>complaint ;-).)
<br>
<br>Using the two namespaces, it's trivial to just alias the one you wa=
nt to
<br>use and not worry about it 99% of the time.<br></blockquote><div><br>Th=
e thing is, the camps are not <i>that</i> separate. Outside of scenarios wh=
ere a project is forbidden from using exceptions, the question is generally=
one of how you want to handle that particular error. If you were given a l=
ist of files to iterate through and accumulate the sizes, if there's an=
error, you want that to be an exception caught by the process that told yo=
u to do it. But if you've been given a directory to iterate through (pe=
rhaps calling the previous function), and the directory is not valid, you w=
ant to handle that error condition locally.<br><br>Same code, different err=
or behavior. This is the kind of coding that I think we should encourage: n=
ot two distinct camps wishing the other one didn't exist, but just peop=
le who use whatever error mechanism is most appropriate at the time.<br></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_11758_125220492.1447445053224--
------=_Part_11757_443443123.1447445053223--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 13 Nov 2015 21:10:33 +0100
Raw View
Le 13/11/2015 20:35, Nicol Bolas a =C3=A9crit :
> On Friday, November 13, 2015 at 2:07:36 PM UTC-5, Vicente J. Botet Escrib=
a
> wrote:
>> Le 13/11/2015 19:08, Nicol Bolas a =C3=A9crit :
>>
>> =20
>> On Friday, November 13, 2015 at 5:13:43 AM UTC-5, Giovanni Piero Deretta
>> wrote:
>>
>> Hi Tony,
>>
>> I strongly agree with most of what you wrote. Just wanted to add a coupl=
e
>> of comments.
>>
>> On Thursday, November 12, 2015 at 8:35:06 PM UTC, Tony V E wrote:
>>
>>
>> So, obviously, you are getting lots of different opinions from different
>> people.
>> For example, Nevin mentioned that he doesn't like basic_string + traits
>> because no one really uses the traits.
>> Other people want/expect that if E is an exception_ptr, it should rethro=
w
>> it, not throw bad_expected_access<exception_ptr>.
>> Some people want it to be consistent, always throw bad_expected_access.
>> Some people want to avoid exceptions.
>> Etc.
>>
>> And this is how the committee works. Or fails to work, sometimes.
>>
>> So you think "allow customization - that will make everyone happy". But
>> even that doesn't, because then those who want simplicity are not happy.
>>
>> We need to look at each facet/opinion carefully. For example, in genera=
l
>> I agree with Nevin - basically the committee tends to over-customize whe=
n
>> the average user doesn't want/need it. But is that the case here? Inst=
ead
>> of saying "OK I won't do traits", maybe you should say "here's how
>> expected<> is different than basic_string...." ie even if we tend to
>> over-customize, maybe this is a case where customization is useful. Or
>> maybe not.
>>
>> So how to decide that?
>>
>> I think we first look at those wanting to avoid exceptions. So they wil=
l
>> use expected<T, MyErrorCode> probably equivalent to expected<T, int>. Or
>> similar.
>> OK. Did they avoid exceptions? Well, almost, but not really. If they
>> call ex.value() without checking, they may still get a
>> bad_expected_access<int> exception. But note - only if they call it. A=
nd
>> I suspect it would be easy for an implementation to just make that UB
>> when/if the developer shuts off exceptions in their compiler.
>>
>> So, 1. we don't need to define expected.value() to have undefined
>> behaviour - it WILL throw. The only question is what it throws. So let=
's
>> not talk about IF it throws. Yes it does.
>>
>>
>>
>> I'm also strongly in favor with ::value throwing an exception.
>>
>>
>> Generally speaking, nobody is opposed to `value` throwing. Even the one
>> person who didn't like it said that it was fine due to consistency with
>> similar interfaces.
>>
>> The question is what it throws. Should it throw a single thing consisten=
tly
>> for all `E`, or should it have special cases? And if it should have spec=
ial
>> cases, should they be customizable? And how do we customize them?
>>
>> Behind all of these is the most important of all: what the *purpose* of
>> this function not throwing a consistent type?
>>
>> E.g. if I have expected<T, variant<E1, ..., En>> I would like to throw E=
i
>> instead of variant<E1, ..., En>.
>> If I have expected<T,exception_ptr> the rethrow the stored exception.
>> If I have error_code throw system_error.
>> ....
>>
> You did not answer my question. What *purpose* does it serve to be able t=
o
> do that. Yes, I understand that you want to throw `E1` if it's packaged i=
n
> a variant or rethrow the exception_ptr or whatever.
>
> *Why do you want to do this?* What do you have to gain by it? How will
> users actually use that to achieve something?
>
>
>> Thus far, the main reason people give for wanting `value` to throw
>> arbitrary things is to be able to merge non-local error interfaces with
>> local error interfaces. So if the caller wants to catch the exception, t=
hey
>> say `.value()` and just catch it wherever. If they do not, then the user
>> uses operator* or otherwise manually test it.
>>
>> My feeling is that any such merger will hurt one kind of error handling =
or
>> the other. And thus, while the idea of merging is well-intensioned, it j=
ust
>> leads to too many problems.
>>
>> The user is already able to implement whatever he wants with operator
>> bool(), operator*() and error().
>> We have two alternatives,
>> * don't provide value() at all or
>> * provide value() throwing the exception with less surprises. E see=
ms
>> to be a first candidate, but it is surprising in some cases, thus the ne=
ed
>> to customizing it.
>> * provide several non-member functions with different approaches
>> - value_or_throw<Exception>(e); // Exception must be constructi=
ble
>> from error(). Throws Exception when there is no value.
>> - value_or_throw<Thrower>(e); // throws the exception defined b=
y
>> Thrower depending on the value error() when there is no value.
>>
>> I like the last one. Instead of customizing the error once for all the
>> user can choose its own customizer.
>>
> I don't know. It seems to me that if the direct user of this object cares
> that much about exactly what exception is thrown when they ask for the
> value... they don't really care much about getting the value. Or at the
> very least, what you have is a statement that's trying to do too much. It=
's
> trying to decide what exception to throw if it's an error, and it's getti=
ng
> the value if it's not.
>
> It makes much more sense for this to be two functions: `value` and
> `throw_if_error<Customization>`. `value` would through the generic error,
> while `throw_if_error` uses the customization to decide what to throw.
>
> That way, users of `value` can treat an exception as a failure in their
> code, as a logic error or precondition violation, rather than something
> that they want to happen.
>
>
>
>> Magic: expected could just "do the right thing". ie if E is exception_p=
tr,
>>
>> then rethrow it. if E is derived from exception, throw it. otherwise
>> throw bad_expected_access<E>.
>>
>> Always Throw E. Simple. But then you get a bunch of ints being thrown.
>> I think this is a no-go option.
>>
>> Always Throw bad_expected_access<E>. Simple. Possibly unexpected. And
>> doesn't "unify" APIs like FileSystem.
>>
>> Templatized: customize via a traits class *passed in* (which could
>> default to magic or whatever). APIs like FileSystem can turns int error=
s
>> into exceptions *at the point when expected.value() is called*. (The "w=
rap
>> E with as_error/as_exception" idea would also go here under "Templatized=
".)
>>
>>
>> NOTE: for FileSystem, the Magic option means, to unify its APIs, it woul=
d
>> need to use exception_ptr (or maybe some E derived from std::exception),=
so
>> that the "right" FileSystem exception is thrown. This is bad for users
>> that want to use FileSystem but avoid exceptions.
>>
>>
>>
>> This I do not understand why would you need exception_ptr?
>>
>>
>> What Tony (and apparently yourself) want is to have APIs provide single
>> functions that don't throw. And therefore, any throwing of exceptions is
>> based on how the caller uses the `expected` return value. So instead of
>> having a `filesystem::file_size` function with two overloads, you just h=
ave
>> one that returns an `expected<size_t, E>`
>>
>> The question is what `E` should be.
>>
>> Right now, `filesystem_error` provides rich information about why the er=
ror
>> happened. Information that is useful to users who catch the exception,
>> possibly far from the throwing location. So if you want to merge the
>> interfaces without the exception users losing information, you must retu=
rn
>> an `expected<T, exception_ptr>`. Or at the very least, `expected<T,
>> filesystem_error>`.
>> =20
>>
>> Or expected<T,E>, where E is a template parameter of the function. See
>> below.
>>
>> Either only use error codes or, better return an expected<T,
>> std::variant<E1, E2...> >. In fact expected should have first class supp=
ort
>> for variant.
>> =20
>>
>>
>> ----
>>
>> Conclusions?
>> 1. If we find we need customization, I don't think it can be external
>> (too many int errors), it needs to be part of the template.
>>
>>
>> I strongly believe that expected should discourage int errors.
>>
>>
>> "strongly discouraging" things will not stop them from happening.
>> `expected` should work with the reality we have, not the one we'd prefer=
..
>>
>> If we have an external customization point that transform the error in a=
n
>> exception, we discourage the use of buil-in types as we can have only on=
e
>> mapping. This doesn't mean that the user can not use expected<T,int>, ju=
st
>> that it can not have a specific exception.
>>
>> 2. I don't think I like exception_ptr. It doesn't help an API like
>>
>> FileSystem that is trying to avoid exceptions. I'd prefer a trait-based
>> customization, or throw E when E is derived from std::exception - becaus=
e
>> you can use std::exception without using exceptions. Can you give me mor=
e
>> uses for expected<T, exception_ptr>?
>>
>>
>>
>> an std::rethrow could map error codes to exception hierarchies.
>>
>>
>> OK, let's say we have some customization scheme that would convert
>> `error_code` to an exception.
>>
>> Look at `filesystem_error <http://en.cppreference.com/w/cpp/experimental=
/fs/filesystem_error> <http://en.cppreference.com/w/cpp/experimental/fs/fil=
esystem_error>`. It
>> has 2 path objects; these exists so that users catching the exception ca=
n
>> actually tell what caused the exception. After all, the location of the
>> catch can be very distant from the immediate caller, so any paths passed=
to
>> the throwing function may have long since been destroyed. Storing the
>> path(s) that caused the error makes sense; it provides the catcher with
>> vital and useful information.
>>
>> `std::error_code` has no such information. So whatever customization sch=
eme
>> you might envision to convert `error_code` into an exception would be
>> *unable* to provide one or more `path` objects. Or any other ancillary d=
ata
>> that is known to the function that returned `expected<T, error_code>`.
>>
>> The only thing you could throw from just an `error_code` is a
>> std::system_error.
>>
>> It all comes back to the same issue: the needs for local error handling =
vs.
>> non-local. A mechanism that is good for one will *necessarily* not be go=
od
>> for the other. Either local error handling gets more data and overhead t=
han
>> they need, or non-local error handling gets less data.
>>
>> In most cases, it is the caller who decides if he wants local or non-loc=
al
>> handling. So the filesystem TS's way of having two APIs is *correct*; it
>> allows each kind of error handler to work in the way that is best for th=
em
>> (minus the whole "output by reference" thing). Nobody gets overhead that
>> they don't need, and everyone is happy.
>>
>> Why change that? Just because you don't like seeing two functions in an
>> interface instead of one?
>>
>>
>> If we want to manage local and remote error handling with different kind
>> of informations, I don't see another way than parameterizing the error
>> condition.
>>
>> I have not think a lot about it but we could add such error condition
>> parameter EC as a template parameter
>>
>> expected<size_t, EC> fsize =3D fs::file_size<EC>(p);
>>
>> =20
>> Now the user can decide the kind of error mechanism he needs.
>>
> Except that it doesn't. Or at least, it's not clear what `EC` means here.
> Are these types that the FileSystem library would provide? Does the
> FileSystem interface impose some concept on `EC`? Does it construct this
> object with paths and other data, and let the type decide which data to
> keep?
What do you think is the best?
>
> Furthermore, if you want a genuine exception, it's not clear how that wou=
ld
> work. An `EC` type could just throw in its constructor, building the
> exception from the parameters. But the caller still gets an
> `expected<size_t, EC>`. Even though it is functionally impossible to
> construct an EC type (since it just throws), you still have to have your
> code go through the `expected`.
An exception object cannot throw.
>
> Would the function have some specialization basedon on the EC type, where
> if it has some property then the function returns `size_t` instead of
> `expected<size_t, EC>`?
Do you want this?
>
> Ultimately, this all sounds like something that's really hard to teach.
> Certainly much more difficult than a simple overload.
>
I believe that you have a lot of imagination.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Nov 2015 13:24:49 -0800 (PST)
Raw View
------=_Part_943_1460850131.1447449890082
Content-Type: multipart/alternative;
boundary="----=_Part_944_1836877010.1447449890082"
------=_Part_944_1836877010.1447449890082
Content-Type: text/plain; charset=UTF-8
On Friday, November 13, 2015 at 3:10:36 PM UTC-5, Vicente J. Botet Escriba
wrote:
>
> > Except that it doesn't. Or at least, it's not clear what `EC` means
> here.
> > Are these types that the FileSystem library would provide? Does the
> > FileSystem interface impose some concept on `EC`? Does it construct this
> > object with paths and other data, and let the type decide which data to
> > keep?
> What do you think is the best?
>
This is *your idea*. You are the one who wants to add this complexity.
Therefore, you are the one who needs to decide which way is best, and to
justify why that is the appropriate way to create such an API.
It's not on me to fix your idea for you. Especially when it's solving a
problem that I believe is best solved with overloads. If you want to
demonstrate that having a single function with a template parameter is
superior to having two overloads, then you need to solve all of the
problems that this creates. And by doing so, you will demonstrate how much
or how little work it would be to implement.
>
> > Furthermore, if you want a genuine exception, it's not clear how that
> would
> > work. An `EC` type could just throw in its constructor, building the
> > exception from the parameters. But the caller still gets an
> > `expected<size_t, EC>`. Even though it is functionally impossible to
> > construct an EC type (since it just throws), you still have to have your
> > code go through the `expected`.
> An exception object cannot throw.
>
The error type most certainly can throw:
class EC
{
public:
EC() {throw some_exception;}
};
Therefore, when the code attempts to initialize an `expected<T, EC>` with
EC, it will emit an exception. If all of the constructors throw, then
`expected<T, EC>` is guaranteed to always have T.
But like I said, you still have to put up with `expected`'s interface, even
though the EC you passed in guarantees that no such `expected` will ever be
in the error state.
>
> > Would the function have some specialization basedon on the EC type,
> where
> > if it has some property then the function returns `size_t` instead of
> > `expected<size_t, EC>`?
> Do you want this?
>
Remember: what I want is for `expected::value` to throw a single exception
type regardless of E, with that exception representing the logical failure
of the user to check an `expected` for an error. I *do not want*
`expected::value` to be used as a way of merging expected and exceptions,
which has been presented as the main reason people want to customize what
kind of exception gets thrown.
My purpose in bringing up what I did was to show that your idea was not
fully formed, or even partially conceived. And therefore, it doesn't make
for a good argument for your position.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_944_1836877010.1447449890082
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, November 13, 2015 at 3:10:36 PM UTC-5, Vicente =
J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> Ex=
cept that it doesn't. Or at least, it's not clear what `EC` means h=
ere.
<br>> Are these types that the FileSystem library would provide? Does th=
e
<br>> FileSystem interface impose some concept on `EC`? Does it construc=
t this
<br>> object with paths and other data, and let the type decide which da=
ta to
<br>> keep?
<br>What do you think is the best?
<br></blockquote><div><br>This is <i>your idea</i>. You are the one who wan=
ts to add this complexity. Therefore, you are the one who needs to decide w=
hich way is best, and to justify why that is the appropriate way to create =
such an API.<br><br>It's not on me to fix your idea for you. Especially=
when it's solving a problem that I believe is best solved with overloa=
ds. If you want to demonstrate that having a single function with a templat=
e parameter is superior to having two overloads, then you need to solve all=
of the problems that this creates. And by doing so, you will demonstrate h=
ow much or how little work it would be to implement.<br><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;">>
<br>> Furthermore, if you want a genuine exception, it's not clear h=
ow that would
<br>> work. An `EC` type could just throw in its constructor, building t=
he
<br>> exception from the parameters. But the caller still gets an
<br>> `expected<size_t, EC>`. Even though it is functionally impos=
sible to
<br>> construct an EC type (since it just throws), you still have to hav=
e your
<br>> code go through the `expected`.
<br>An exception object cannot throw.<br></blockquote><div><br>The error ty=
pe most certainly can throw:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> EC<br></span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>public</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 E=
C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">throw</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> some_exception</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};</span></div></code></div><br>Therefore, when t=
he code attempts to initialize an `expected<T, EC>` with EC, it will =
emit an exception. If all of the constructors throw, then `expected<T, E=
C>` is guaranteed to always have T.<br><br>But like I said, you still ha=
ve to put up with `expected`'s interface, even though the EC you passed=
in guarantees that no such `expected` will ever be in the error state.<br>=
<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>> Would the function have some specialization basedon on the EC type=
, where
<br>> if it has some property then the function returns `size_t` instead=
of
<br>> `expected<size_t, EC>`?
<br>Do you want this?<br></blockquote><div><br>Remember: what I want is for=
`expected::value` to throw a single exception type regardless of E, with t=
hat exception representing the logical failure of the user to check an `exp=
ected` for an error. I <i>do not want</i> `expected::value` to be used as a=
way of merging expected and exceptions, which has been presented as the ma=
in reason people want to customize what kind of exception gets thrown.<br><=
br>My purpose in bringing up what I did was to show that your idea was not =
fully formed, or even partially conceived. And therefore, it doesn't ma=
ke for a good argument for your position.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_944_1836877010.1447449890082--
------=_Part_943_1460850131.1447449890082--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 14 Nov 2015 00:20:30 +0100
Raw View
Le 13/11/2015 22:24, Nicol Bolas a =C3=A9crit :
> On Friday, November 13, 2015 at 3:10:36 PM UTC-5, Vicente J. Botet Escrib=
a
> wrote:
>>> Except that it doesn't. Or at least, it's not clear what `EC` means
>> here.
>>> Are these types that the FileSystem library would provide? Does the
>>> FileSystem interface impose some concept on `EC`? Does it construct thi=
s
>>> object with paths and other data, and let the type decide which data to
>>> keep?
>> What do you think is the best?
>>
> This is *your idea*. You are the one who wants to add this complexity.
> Therefore, you are the one who needs to decide which way is best, and to
> justify why that is the appropriate way to create such an API.
>
> It's not on me to fix your idea for you. Especially when it's solving a
> problem that I believe is best solved with overloads. If you want to
> demonstrate that having a single function with a template parameter is
> superior to having two overloads, then you need to solve all of the
> problems that this creates. And by doing so, you will demonstrate how muc=
h
> or how little work it would be to implement.
>
What I mean is that you are asking for questions I think you know the=20
answer, or you have a good idea of what you will be for or against. Am I=20
wrong?
>>> Furthermore, if you want a genuine exception, it's not clear how that
>> would
>>> work. An `EC` type could just throw in its constructor, building the
>>> exception from the parameters. But the caller still gets an
>>> `expected<size_t, EC>`. Even though it is functionally impossible to
>>> construct an EC type (since it just throws), you still have to have you=
r
>>> code go through the `expected`.
>> An exception object cannot throw.
>>
> The error type most certainly can throw:
>
> class EC
> {
> public:
> EC() {throw some_exception;}
> };
>
> Therefore, when the code attempts to initialize an `expected<T, EC>` with
> EC, it will emit an exception. If all of the constructors throw, then
> `expected<T, EC>` is guaranteed to always have T.
>
> But like I said, you still have to put up with `expected`'s interface, ev=
en
> though the EC you passed in guarantees that no such `expected` will ever =
be
> in the error state.
>
>
>
>>> Would the function have some specialization basedon on the EC type,
>> where
>>> if it has some property then the function returns `size_t` instead of
>>> `expected<size_t, EC>`?
>> Do you want this?
>>
> Remember: what I want is for `expected::value` to throw a single exceptio=
n
> type regardless of E, with that exception representing the logical failur=
e
> of the user to check an `expected` for an error. I *do not want*
> `expected::value` to be used as a way of merging expected and exceptions,
> which has been presented as the main reason people want to customize what
> kind of exception gets thrown.
>
> My purpose in bringing up what I did was to show that your idea was not
> fully formed, or even partially conceived. And therefore, it doesn't make
> for a good argument for your position.
>
You are asking me to replay to your design choices. Sorry, I have no=20
answer for those. If you don't want what you are asking, I don't see the=20
need to answer the question.
I don't need that you tell me that the idea was not fully formed. It was=20
already clear from what I said:
"I have not think a lot about it but ...."
Vicente
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 13 Nov 2015 16:38:53 -0800 (PST)
Raw View
------=_Part_25_1180697723.1447461533568
Content-Type: multipart/alternative;
boundary="----=_Part_26_1110196276.1447461533568"
------=_Part_26_1110196276.1447461533568
Content-Type: text/plain; charset=UTF-8
OK, here is where I feel we are in the conversation.
People seem to want `value` to throw different, customization exceptions.
And as far as I can tell, the main (or only) reason to do so is to allow
people to write a single API function, which uses exceptions based on how
the return value is used. This would achieving the effect of FileSystem
TS's design, but without multiple overloads.
I've demonstrated that a straightforward implementation of this is not
viable. It will result in either local try/catch blocks just to handle
simple error codes and lots of redundant data, or non-local functions will
not have enough information to fully resolve the error. There does not seem
to be a middle way; one side or the other always seems to lose.
Vicente put forth a sketch of an idea for unifying such APIs. But the idea
lacked any real details, so it's not clear if it would actually resolve the
problem.
If it is not possible to develop such a way, to have a single function
provide both local and non-local exceptions without overloading, then I
submit that there is no reason to give `value` customized exceptions. Since
that seemed to be the primary motivation, if it's not possible, then it
seems to me that there is no motivation for this feature.
It seems to me that there are two outstanding questions:
1) Is there an effective means to have one function, based on `expected`,
which services the needs of local and non-local error handling just as well
as having two overloads? Is there a fleshed-out design for such an
interface?
2) What do you need to be able to do that requires `value` to throw
customized exceptions? And again, don't just say "I want `expected<T,
variant<E1, E2,...>>` to throw the particular error in the variant." You
need to explain *why* you need `value` to do that. Explain what you are
trying to do that makes this behavior important.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_26_1110196276.1447461533568
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">OK, here is where I feel we are in the conversation.<br><b=
r>People seem to want `value` to throw different, customization exceptions.=
And as far as I can tell, the main (or only) reason to do so is to allow p=
eople to write a single API function, which uses exceptions based on how th=
e return value is used. This would achieving the effect of FileSystem TS=
9;s design, but without multiple overloads.<br><br>I've demonstrated th=
at a straightforward implementation of this is not viable. It will result i=
n either local try/catch blocks just to handle simple error codes and lots =
of redundant data, or non-local functions will not have enough information =
to fully resolve the error. There does not seem to be a middle way; one sid=
e or the other always seems to lose.<br><br>Vicente put forth a sketch of a=
n idea for unifying such APIs. But the idea lacked any real details, so it&=
#39;s not clear if it would actually resolve the problem.<br><br>If it is n=
ot possible to develop such a way, to have a single function=20
provide both local and non-local exceptions without overloading, then I=20
submit that there is no reason to give `value` customized exceptions.=20
Since that seemed to be the primary motivation, if it's not possible,=
=20
then it seems to me that there is no motivation for this feature.<br><br>It=
seems to me that there are two outstanding questions:<br><br>1) Is there a=
n effective means to have one function, based on `expected`, which services=
the needs of local and non-local error handling just as well as having two=
overloads? Is there a fleshed-out design for such an interface?<br><br>2) =
What do you need to be able to do that requires `value` to throw customized=
exceptions? And again, don't just say "I want `expected<T,=20
variant<E1, E2,...>>` to throw the particular error in the=20
variant." You need to explain <i>why</i> you need `value` to do that. =
Explain what you are trying to do that makes this behavior important.<br></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_26_1110196276.1447461533568--
------=_Part_25_1180697723.1447461533568--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 14 Nov 2015 09:54:06 +0100
Raw View
Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
> OK, here is where I feel we are in the conversation.
>
> People seem to want `value` to throw different, customization exceptions.
> And as far as I can tell, the main (or only) reason to do so is to allow
> people to write a single API function, which uses exceptions based on how
> the return value is used. This would achieving the effect of FileSystem
> TS's design, but without multiple overloads.
>
> I've demonstrated that a straightforward implementation of this is not
> viable. It will result in either local try/catch blocks just to handle
> simple error codes and lots of redundant data, or non-local functions wil=
l
> not have enough information to fully resolve the error. There does not se=
em
> to be a middle way; one side or the other always seems to lose.
Hmm, I believe you demonstrated that expected<T,exception_ptr> is not a=20
good candidate to manage local recovery.
expected<T,filesystem_error> should be a better candidate.
I suggest to start a specific thread for how expected can improve=20
FileSystem TS interface (if any), independently of whether there are two=20
overload or only one.
>
> Vicente put forth a sketch of an idea for unifying such APIs. But the ide=
a
> lacked any real details, so it's not clear if it would actually resolve t=
he
> problem.
Right, it is an idea as said.
> If it is not possible to develop such a way, to have a single function
> provide both local and non-local exceptions without overloading, then I
> submit that there is no reason to give `value` customized exceptions. Sin=
ce
> that seemed to be the primary motivation, if it's not possible, then it
> seems to me that there is no motivation for this feature.
I give other useful customization cases.
>
> It seems to me that there are two outstanding questions:
>
> 1) Is there an effective means to have one function, based on `expected`,
> which services the needs of local and non-local error handling just as we=
ll
> as having two overloads? Is there a fleshed-out design for such an
> interface?
It depends if people want to find a solution or not. IMHO, nobody has=20
spent enough time to presented a proposal on how to use expected for=20
FileSystem TS.
>
> 2) What do you need to be able to do that requires `value` to throw
> customized exceptions? And again, don't just say "I want `expected<T,
> variant<E1, E2,...>>` to throw the particular error in the variant." You
> need to explain *why* you need `value` to do that. Explain what you are
> trying to do that makes this behavior important.
>
I want expected<T, variant<E1, ...>> to throw the particular error in=20
the variant :)
Why? Because a function can have several kind of errors.
E.g. expected<T, variant<error_code, filesystem_error>>
Some time ago I suggested a variadic version of expected
expected<T, error_code, filesystem_error>
This gives you local and non-local error reporting tool. That you could=20
prefer two overloaded function is another matter.
Vicente
P.S. Don't forget we a constructing an expected proposal, that respond=20
to the user needs (and the standard library can be a user).
P.S.S. expected proposal has a visitation interface
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 14 Nov 2015 10:33:44 +0100
Raw View
Le 14/11/2015 09:54, Vicente J. Botet Escriba a =C3=A9crit :
> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
>> OK, here is where I feel we are in the conversation.
>>
>> People seem to want `value` to throw different, customization=20
>> exceptions.
>> And as far as I can tell, the main (or only) reason to do so is to allow
>> people to write a single API function, which uses exceptions based on=20
>> how
>> the return value is used. This would achieving the effect of FileSystem
>> TS's design, but without multiple overloads.
>>
>> I've demonstrated that a straightforward implementation of this is not
>> viable. It will result in either local try/catch blocks just to handle
>> simple error codes and lots of redundant data, or non-local functions=20
>> will
>> not have enough information to fully resolve the error. There does=20
>> not seem
>> to be a middle way; one side or the other always seems to lose.
> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not=20
> a good candidate to manage local recovery.
> expected<T,filesystem_error> should be a better candidate.
>
> I suggest to start a specific thread for how expected can improve=20
> FileSystem TS interface (if any), independently of whether there are=20
> two overload or only one.
>>
>> Vicente put forth a sketch of an idea for unifying such APIs. But the=20
>> idea
>> lacked any real details, so it's not clear if it would actually=20
>> resolve the
>> problem.
> Right, it is an idea as said.
template <class EC>
requires Same<EC, error_code> or Same<EC, filesystem::filesystem_error>
expected<X, EC> filesystem::function(...);
auto x =3D filesystem::function<error_code>(...);
or
auto x =3D filesystem::function<filesystem::filesystem_error>(...);
The filesystem function know at compile time which kind of error must be=20
reported and could at compile time build it without any performance penalty=
..
EC can have even be defaulted.
auto x =3D filesystem::function(...);
>> If it is not possible to develop such a way, to have a single function
>> provide both local and non-local exceptions without overloading, then I
>> submit that there is no reason to give `value` customized exceptions.=20
>> Since
>> that seemed to be the primary motivation, if it's not possible, then it
>> seems to me that there is no motivation for this feature.
> I give other useful customization cases.
>>
>> It seems to me that there are two outstanding questions:
>>
>> 1) Is there an effective means to have one function, based on=20
>> `expected`,
>> which services the needs of local and non-local error handling just=20
>> as well
>> as having two overloads? Is there a fleshed-out design for such an
>> interface?
> It depends if people want to find a solution or not. IMHO, nobody has=20
> spent enough time to presented a proposal on how to use expected for=20
> FileSystem TS.
>>
>> 2) What do you need to be able to do that requires `value` to throw
>> customized exceptions? And again, don't just say "I want `expected<T,
>> variant<E1, E2,...>>` to throw the particular error in the variant." You
>> need to explain *why* you need `value` to do that. Explain what you are
>> trying to do that makes this behavior important.
>>
> I want expected<T, variant<E1, ...>> to throw the particular error in=20
> the variant :)
> Why? Because a function can have several kind of errors.
> E.g. expected<T, variant<error_code, filesystem_error>>
>
Sorry, this should not work for FileSystem, as the user need to state=20
which kind of error she wants.
Anyway, you see what I mean. If now a function can throw exceptions E1,=20
...., En, transforming it to expected would result in expected<T,=20
variant<E1, ..., En>> and the less surprising exception to throw when=20
value is called is IMO Ei.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 06:49:12 -0800 (PST)
Raw View
------=_Part_321_1128467115.1447512552755
Content-Type: multipart/alternative;
boundary="----=_Part_322_937041662.1447512552756"
------=_Part_322_937041662.1447512552756
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :=20
> > OK, here is where I feel we are in the conversation.=20
> >=20
> > People seem to want `value` to throw different, customization=20
> exceptions.=20
> > And as far as I can tell, the main (or only) reason to do so is to allo=
w=20
> > people to write a single API function, which uses exceptions based on=
=20
> how=20
> > the return value is used. This would achieving the effect of FileSystem=
=20
> > TS's design, but without multiple overloads.=20
> >=20
> > I've demonstrated that a straightforward implementation of this is not=
=20
> > viable. It will result in either local try/catch blocks just to handle=
=20
> > simple error codes and lots of redundant data, or non-local functions=
=20
> will=20
> > not have enough information to fully resolve the error. There does not=
=20
> seem=20
> > to be a middle way; one side or the other always seems to lose.=20
> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not a=
=20
> good candidate to manage local recovery.=20
> expected<T,filesystem_error> should be a better candidate.
>
You will recall that one of my arguments was about bloat.=20
`filesystem_error` contains up to two `path` objects, which given small=20
string optimization and its error_code make the resulting=20
`filesystem_error` object take up *at least* 40 bytes (16 per `path`, + 8=
=20
for the error code). That doesn't even count the vtable pointer (since it's=
=20
derived from `std::exception`.
That's not to mention the overhead of passing back a path that the local=20
context already has. Which may mean allocating memory, depending on the=20
path's length.
This improves on the original only in that you don't have to throw the=20
exception in order to introspect it. But you are still creating needless=20
overhead for local error handling users. It's biased towards those using=20
exceptions.
Oh, and I believe you said this on another thread:
> If E means Error, we can not throw another error while copying it.
If we are to follow that requirement, then you *cannot *embed `path`=20
objects in the return value either, for the same reason you can't use=20
`std::string`. Both of them have throwing copy operations (but they are=20
no-throw moveable). So filesystem_error couldn't be used.
This requirement would also mean that you couldn't put a lot of flavorful=
=20
error types into the object. That's fine for simple error codes and the=20
like. But not for the kinds of objects that are appropriate for exceptions.
So by your own design ideas, what you suggested is forbidden.
I suggest to start a specific thread for how expected can improve=20
> FileSystem TS interface (if any), independently of whether there are two=
=20
> overload or only one.
>
FileSystem is relevant to this thread because APIs like it are the primary=
=20
motivation for wanting expected to have customized exceptions on `value`.
Every reason people want this customization ultimately boils down to "I=20
want a function to support local and non-local errors with only one=20
overload." That's why the FileSystem TS interface is important; it's a=20
perfect use case to prove that your customization design is functional. If=
=20
a particular customization design can't solve the FileSystem TS issue=20
adequately, then it's clear that this particular customization design isn't=
=20
going to actually solve the problem at all.
So the best way to judge any suggested customization mechanism is to judge=
=20
it by whether it solves the problem that people want it to solve. And=20
FileSystem is an excellent example of that problem.
>=20
> > Vicente put forth a sketch of an idea for unifying such APIs. But the=
=20
> idea=20
> > lacked any real details, so it's not clear if it would actually resolve=
=20
> the=20
> > problem.=20
> Right, it is an idea as said.=20
> > If it is not possible to develop such a way, to have a single function=
=20
> > provide both local and non-local exceptions without overloading, then I=
=20
> > submit that there is no reason to give `value` customized exceptions.=
=20
> Since=20
> > that seemed to be the primary motivation, if it's not possible, then it=
=20
> > seems to me that there is no motivation for this feature.=20
> I give other useful customization cases.
>
No, you stated the behavior you wanted to customize. You didn't say why you=
=20
wanted to do it. That would be the motivation part.
>=20
> > It seems to me that there are two outstanding questions:=20
> >=20
> > 1) Is there an effective means to have one function, based on=20
> `expected`,=20
> > which services the needs of local and non-local error handling just as=
=20
> well=20
> > as having two overloads? Is there a fleshed-out design for such an=20
> > interface?=20
> It depends if people want to find a solution or not. IMHO, nobody has=20
> spent enough time to presented a proposal on how to use expected for=20
> FileSystem TS.=20
> >=20
> > 2) What do you need to be able to do that requires `value` to throw=20
> > customized exceptions? And again, don't just say "I want `expected<T,=
=20
> > variant<E1, E2,...>>` to throw the particular error in the variant." Yo=
u=20
> > need to explain *why* you need `value` to do that. Explain what you are=
=20
> > trying to do that makes this behavior important.=20
> >=20
> I want expected<T, variant<E1, ...>> to throw the particular error in=20
> the variant :)=20
> Why? Because a function can have several kind of errors.=20
> E.g. expected<T, variant<error_code, filesystem_error>>=20
>
>
> Some time ago I suggested a variadic version of expected=20
> expected<T, error_code, filesystem_error>=20
> This gives you local and non-local error reporting tool.
This is better for local error handling, since you're not passing back data=
=20
that the local context already has. But it still causes bloat to the size=
=20
of `expected`.
It also makes such a multi-variant becomes a *lot* more difficult to work=
=20
with. I'm pretty sure you'd lose your precious `await` propagation, since=
=20
`await` has no way of knowing which error to fetch, which has to be a=20
*compile-time* selection of a *runtime-defined* value. Even visitation=20
wouldn't work, since you can't return different types.
This design also forces people to use an awkward `std::get`-style interface=
=20
to get the particular error out, as opposed to the much simpler `.error`.
This is what we would call "scope creep". It comes from having a poor=20
vision of the overall design for the type, from trying to make a type that=
=20
solves *everyone's* problems. It tends to end up with a type that solves=20
everyone's problems, but does so very sub-optimally.
My vision of `expected` is this: it's for local/non-throwing error=20
handling. To that end, it should be as simple to use as possible, with a=20
clear and obvious API and minimal overhead.
Multiple error types are not useful for local handling; having multiple=20
error types is useful only for two cases. 1) Single-function local and=20
non-local error handling, as in your case above. And 2) the ability to=20
propagate errors out of a function from multiple `expected` sources. Well,=
=20
if `expected` is for local handling, its ability to propagate errors is=20
irrelevant (you don't propagate errors if you're handling them locally). So=
=20
too is its ability to allow single-function non-local error handling.
I would much rather have `expected<T, E>`, which is simple and easy to use.=
=20
If you want to use `expected` outside of local error handling, then its=20
interface will become increasingly more complicated. Keep the main class=20
simple to use. So people who want to use the type against its purpose=20
should have to do `expected<T, variant<E1, E2, ...>>` explicitly. Yes,=20
that's a lot harder to use, but you would only use it when you're using=20
`expected` for something that `expected` isn't really meant to do.
That you could=20
> prefer two overloaded function is another matter.=20
>
> Vicente=20
>
> P.S. Don't forget we a constructing an expected proposal, that respond=20
> to the user needs (and the standard library can be a user).=20
>
> P.S.S. expected proposal has a visitation interface=20
>
A visitation interface would only be reasonable for `expected` if it=20
allowed multiple error types natively. Otherwise, nobody would use it. And=
=20
even then, you would only visit it for the errors within it.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_322_937041662.1447512552756
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J. Botet Escrib=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 14/11/2015 01:38, N=
icol Bolas a =C3=A9crit :
<br>> OK, here is where I feel we are in the conversation.
<br>>
<br>> People seem to want `value` to throw different, customization exce=
ptions.
<br>> And as far as I can tell, the main (or only) reason to do so is to=
allow
<br>> people to write a single API function, which uses exceptions based=
on how
<br>> the return value is used. This would achieving the effect of FileS=
ystem
<br>> TS's design, but without multiple overloads.
<br>>
<br>> I've demonstrated that a straightforward implementation of thi=
s is not
<br>> viable. It will result in either local try/catch blocks just to ha=
ndle
<br>> simple error codes and lots of redundant data, or non-local functi=
ons will
<br>> not have enough information to fully resolve the error. There does=
not seem
<br>> to be a middle way; one side or the other always seems to lose.
<br>Hmm, I believe you demonstrated that expected<T,exception_ptr> is=
not a=20
<br>good candidate to manage local recovery.
<br>expected<T,filesystem_error> should be a better candidate.<br></b=
lockquote><div><br>You will recall that one of my arguments was about bloat=
.. `filesystem_error` contains up to two `path` objects, which given small s=
tring optimization and its error_code make the resulting `filesystem_error`=
object take up <i>at least</i> 40 bytes (16 per `path`, + 8 for the error =
code). That doesn't even count the vtable pointer (since it's deriv=
ed from `std::exception`.<br><br>That's not to mention the overhead of =
passing back a path that the local context already has. Which may mean allo=
cating memory, depending on the path's length.<br><br>This improves on =
the original only in that you don't have to throw the exception in orde=
r to introspect it. But you are still creating needless overhead for local =
error handling users. It's biased towards those using exceptions.<br><b=
r>Oh, and I believe you said this on another thread:<br><br>> If E means=
Error, we can not throw another error while copying it.<br><br>If we are t=
o follow that requirement, then you <i>cannot </i>embed `path` objects in t=
he return value either, for the same reason you can't use `std::string`=
.. Both of them have throwing copy operations (but they are no-throw moveabl=
e). So filesystem_error couldn't be used.<br><br>This requirement would=
also mean that you couldn't put a lot of flavorful error types into th=
e object. That's fine for simple error codes and the like. But not for =
the kinds of objects that are appropriate for exceptions.<br><br>So by your=
own design ideas, what you suggested is forbidden.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
I suggest to start a specific thread for how expected can improve=20
<br>FileSystem TS interface (if any), independently of whether there are tw=
o=20
<br>overload or only one.<br></blockquote><div><br>FileSystem is relevant t=
o this thread because APIs like it are the primary motivation for wanting e=
xpected to have customized exceptions on `value`.<br><br>Every reason peopl=
e want this customization ultimately boils down to "I want a function =
to support local and non-local errors with only one overload." That=
9;s why the FileSystem TS interface is important; it's a perfect use ca=
se to prove that your customization design is functional. If a particular c=
ustomization design can't solve the FileSystem TS issue adequately, the=
n it's clear that this particular customization design isn't going =
to actually solve the problem at all.<br><br>So the best way to judge any s=
uggested customization mechanism is to judge it by whether it solves the pr=
oblem that people want it to solve. And FileSystem is an excellent example =
of that problem.<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
>
<br>> Vicente put forth a sketch of an idea for unifying such APIs. But =
the idea
<br>> lacked any real details, so it's not clear if it would actuall=
y resolve the
<br>> problem.
<br>Right, it is an idea as said.
<br>> If it is not possible to develop such a way, to have a single func=
tion
<br>> provide both local and non-local exceptions without overloading, t=
hen I
<br>> submit that there is no reason to give `value` customized exceptio=
ns. Since
<br>> that seemed to be the primary motivation, if it's not possible=
, then it
<br>> seems to me that there is no motivation for this feature.
<br>I give other useful customization cases.<br></blockquote><div><br>No, y=
ou stated the behavior you wanted to customize. You didn't say why you =
wanted to do it. That would be the motivation part.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">>
<br>> It seems to me that there are two outstanding questions:
<br>>
<br>> 1) Is there an effective means to have one function, based on `exp=
ected`,
<br>> which services the needs of local and non-local error handling jus=
t as well
<br>> as having two overloads? Is there a fleshed-out design for such an
<br>> interface?
<br>It depends if people want to find a solution or not. IMHO, nobody has=
=20
<br>spent enough time to presented a proposal on how to use expected for=20
<br>FileSystem TS.
<br>>
<br>> 2) What do you need to be able to do that requires `value` to thro=
w
<br>> customized exceptions? And again, don't just say "I want =
`expected<T,
<br>> variant<E1, E2,...>>` to throw the particular error in th=
e variant." You
<br>> need to explain *why* you need `value` to do that. Explain what yo=
u are
<br>> trying to do that makes this behavior important.
<br>>
<br>I want expected<T, variant<E1, ...>> to throw the particula=
r error in=20
<br>the variant :)
<br>Why? Because a function can have several kind of errors.
<br>E.g. expected<T, variant<error_code, filesystem_error>>
<br>
<br>
<br>Some time ago I suggested a variadic version of expected
<br>expected<T, error_code, filesystem_error>=C2=A0</blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<br>This gives you local and non-local error reporting tool.</blockquote><d=
iv><br>This is better for local error handling, since you're not passin=
g back data that the local context already has. But it still causes bloat t=
o the size of `expected`.<br><br>It also makes such a multi-variant becomes=
a <i>lot</i> more difficult to work with. I'm pretty sure you'd lo=
se your precious `await` propagation, since `await` has no way of knowing w=
hich error to fetch, which has to be a <i>compile-time</i> selection of a <=
i>runtime-defined</i> value. Even visitation wouldn't work, since you c=
an't return different types.<br><br>This design also forces people to u=
se an awkward `std::get`-style interface to get the particular error out, a=
s opposed to the much simpler `.error`.<br><br>This is what we would call &=
quot;scope creep". It comes from having a poor vision of the overall d=
esign for the type, from trying to make a type that solves <i>everyone'=
s</i> problems. It tends to end up with a type that solves everyone's p=
roblems, but does so very sub-optimally.<br><br>My vision of `expected` is =
this: it's for local/non-throwing error handling. To that end, it shoul=
d be as simple to use as possible, with a clear and obvious API and minimal=
overhead.<br><br>Multiple error types are not useful for local handling; h=
aving multiple error types is useful only for two cases. 1) Single-function=
local and non-local error handling, as in your case above. And 2) the abil=
ity to propagate errors out of a function from multiple `expected` sources.=
Well, if `expected` is for local handling, its ability to propagate errors=
is irrelevant (you don't propagate errors if you're handling them =
locally). So too is its ability to allow single-function non-local error ha=
ndling.<br><br>I would much rather have `expected<T, E>`, which is si=
mple and easy to use. If you want to use `expected` outside of local error =
handling, then its interface will become increasingly more complicated. Kee=
p the main class simple to use. So people who want to use the type against =
its purpose should have to do `expected<T, variant<E1, E2, ...>>=
;` explicitly. Yes, that's a lot harder to use, but you would only use =
it when you're using `expected` for something that `expected` isn't=
really meant to do.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"> That you could=20
<br>prefer two overloaded function is another matter.
<br>
<br>Vicente
<br>
<br>P.S. Don't forget we a constructing an expected proposal, that resp=
ond=20
<br>to the user needs (and the standard library can be a user).
<br>
<br>P.S.S. expected proposal has a visitation interface
<br></blockquote><div><br>A visitation interface would only be reasonable f=
or `expected` if it allowed multiple error types natively. Otherwise, nobod=
y would use it. And even then, you would only visit it for the errors withi=
n it.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_322_937041662.1447512552756--
------=_Part_321_1128467115.1447512552755--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 07:37:17 -0800 (PST)
Raw View
------=_Part_393_297420285.1447515437837
Content-Type: multipart/alternative;
boundary="----=_Part_394_1600638808.1447515437838"
------=_Part_394_1600638808.1447515437838
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 4:33:48 AM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 14/11/2015 09:54, Vicente J. Botet Escriba a =C3=A9crit :=20
> > Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :=20
> >> OK, here is where I feel we are in the conversation.=20
> >>=20
> >> People seem to want `value` to throw different, customization=20
> >> exceptions.=20
> >> And as far as I can tell, the main (or only) reason to do so is to=20
> allow=20
> >> people to write a single API function, which uses exceptions based on=
=20
> >> how=20
> >> the return value is used. This would achieving the effect of FileSyste=
m=20
> >> TS's design, but without multiple overloads.=20
> >>=20
> >> I've demonstrated that a straightforward implementation of this is not=
=20
> >> viable. It will result in either local try/catch blocks just to handle=
=20
> >> simple error codes and lots of redundant data, or non-local functions=
=20
> >> will=20
> >> not have enough information to fully resolve the error. There does=20
> >> not seem=20
> >> to be a middle way; one side or the other always seems to lose.=20
> > Hmm, I believe you demonstrated that expected<T,exception_ptr> is not=
=20
> > a good candidate to manage local recovery.=20
> > expected<T,filesystem_error> should be a better candidate.=20
> >=20
> > I suggest to start a specific thread for how expected can improve=20
> > FileSystem TS interface (if any), independently of whether there are=20
> > two overload or only one.=20
> >>=20
> >> Vicente put forth a sketch of an idea for unifying such APIs. But the=
=20
> >> idea=20
> >> lacked any real details, so it's not clear if it would actually=20
> >> resolve the=20
> >> problem.=20
> > Right, it is an idea as said.=20
> template <class EC>=20
> requires Same<EC, error_code> or Same<EC, filesystem::filesystem_error>=
=20
> expected<X, EC> filesystem::function(...);=20
>
> auto x =3D filesystem::function<error_code>(...);=20
> or=20
> auto x =3D filesystem::function<filesystem::filesystem_error>(...);=
=20
>
> The filesystem function know at compile time which kind of error must be=
=20
> reported and could at compile time build it without any performance=20
> penalty.
>
OK, that's a design. It provides zero overhead for local handlers. Though=
=20
it does cause some overhead for non-local handlers; the `filesystem_error`=
=20
has to be constructed, then copied into the actual exception.
So, what does the implementation of, for example `file_size` look like?=20
Well, it would look something like this:
template<typename EC>
//Insert various machinery to SFINAE ensure EC's types.
expected<uintmax_t, EC> file_size(path p)
{
auto sz =3D //get actual file size.
if(/*did error*/)
{
return ConstructError<EC>("filesystem::file_size", p, /*Get error code*=
/
);
}
return sz;
}
Where `ConstructError<EC>` constructs an `unexpected_type<EC>`, using=20
different logic based on whether EC was an error_code or a=20
filesystem_error. There would be different overloads of `ConstructError`=20
for the different `filesystem_error` constructor variants.
After looking at Boost.FileSystem, this doesn't seem like much of a=20
difference compared to the way they implement error handling. They have one=
=20
primary implementation function that takes an error_code by pointer, which=
=20
throws if the pointer is NULL. The actual API functions are all just=20
one-liners in the header, which call the main function with a null or=20
non-null pointer.
Oh, and something I realized while writing this. Above, I said that the=20
filesystem_error has to be copied into the exception. Well, the user ought=
=20
to have some say in that, since copying takes up precious performance. I=20
would suggest having an overload of `value` based on & and && `this`=20
qualifiers:
const T &value() const &;
T value() &&;
In the first case, it will return a reference to T or throw a copy of E (or=
=20
whatever the customization mechanism deduces to). In the second case, it=20
returns a move-constructed T or throws a *move-constructed* E (via=20
something like `throw std::move(std::move(*this).error())`.
The point of this is to allow for the user to do this:
uintmax_t size =3D fs::file_size(p).value();
Because the return value is an prvalue, it should call the && overload of=
=20
`value`. That will move T out (which is just a copy), but in the event of=
=20
an exception, it will move-construct the exception object from the=20
`filesystem_error`. That will help minimize the overhead to exception=20
users. It will also help minimize the chance of throwing an exception=20
during the construction of the exception object (path, for example, is=20
nothrow moveable).
Of course, this also means that whatever exception customization mechanism=
=20
you come up with will need to allow for similar forwarding of move intent.
EC can have even be defaulted.=20
>
> auto x =3D filesystem::function(...);=20
>
>
>
> >> If it is not possible to develop such a way, to have a single function=
=20
> >> provide both local and non-local exceptions without overloading, then =
I=20
> >> submit that there is no reason to give `value` customized exceptions.=
=20
> >> Since=20
> >> that seemed to be the primary motivation, if it's not possible, then i=
t=20
> >> seems to me that there is no motivation for this feature.=20
> > I give other useful customization cases.=20
> >>=20
> >> It seems to me that there are two outstanding questions:=20
> >>=20
> >> 1) Is there an effective means to have one function, based on=20
> >> `expected`,=20
> >> which services the needs of local and non-local error handling just=20
> >> as well=20
> >> as having two overloads? Is there a fleshed-out design for such an=20
> >> interface?=20
> > It depends if people want to find a solution or not. IMHO, nobody has=
=20
> > spent enough time to presented a proposal on how to use expected for=20
> > FileSystem TS.=20
> >>=20
> >> 2) What do you need to be able to do that requires `value` to throw=20
> >> customized exceptions? And again, don't just say "I want `expected<T,=
=20
> >> variant<E1, E2,...>>` to throw the particular error in the variant."=
=20
> You=20
> >> need to explain *why* you need `value` to do that. Explain what you ar=
e=20
> >> trying to do that makes this behavior important.=20
> >>=20
> > I want expected<T, variant<E1, ...>> to throw the particular error in=
=20
> > the variant :)=20
> > Why? Because a function can have several kind of errors.=20
> > E.g. expected<T, variant<error_code, filesystem_error>>=20
> >=20
> Sorry, this should not work for FileSystem, as the user need to state=20
> which kind of error she wants.=20
>
> Anyway, you see what I mean. If now a function can throw exceptions E1,=
=20
> ..., En, transforming it to expected would result in expected<T,=20
> variant<E1, ..., En>> and the less surprising exception to throw when=20
> value is called is IMO Ei.
>
If you have an API that throws, merely sticking those exceptions in an=20
`expected`, even as the actual exception types themselves (rather than=20
`exception_ptr`), causes bloat for local error handling. That's why your=20
FileSystem design above returns *different* error types based on the user=
=20
desiring local or non-local handling.
So there's no reason for a user to want to take a function that could throw=
=20
some number of exceptions and turn it into a function that is an `expected`=
=20
over *exactly* those exception types. That would be a bad API, for reasons=
=20
we've discussed. And therefore, this is not a good reason to have `value`=
=20
introspect a `variant` and throw the individual item.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_394_1600638808.1447515437838
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 4:33:48 AM UTC-5, Vicente J. Botet Escrib=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 14/11/2015 09:54, V=
icente J. Botet Escriba a =C3=A9crit :
<br>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
<br>>> OK, here is where I feel we are in the conversation.
<br>>>
<br>>> People seem to want `value` to throw different, customization=
=20
<br>>> exceptions.
<br>>> And as far as I can tell, the main (or only) reason to do so i=
s to allow
<br>>> people to write a single API function, which uses exceptions b=
ased on=20
<br>>> how
<br>>> the return value is used. This would achieving the effect of F=
ileSystem
<br>>> TS's design, but without multiple overloads.
<br>>>
<br>>> I've demonstrated that a straightforward implementation of=
this is not
<br>>> viable. It will result in either local try/catch blocks just t=
o handle
<br>>> simple error codes and lots of redundant data, or non-local fu=
nctions=20
<br>>> will
<br>>> not have enough information to fully resolve the error. There =
does=20
<br>>> not seem
<br>>> to be a middle way; one side or the other always seems to lose=
..
<br>> Hmm, I believe you demonstrated that expected<T,exception_ptr&g=
t; is not=20
<br>> a good candidate to manage local recovery.
<br>> expected<T,filesystem_error> should be a better candidate.
<br>>
<br>> I suggest to start a specific thread for how expected can improve=
=20
<br>> FileSystem TS interface (if any), independently of whether there a=
re=20
<br>> two overload or only one.
<br>>>
<br>>> Vicente put forth a sketch of an idea for unifying such APIs. =
But the=20
<br>>> idea
<br>>> lacked any real details, so it's not clear if it would act=
ually=20
<br>>> resolve the
<br>>> problem.
<br>> Right, it is an idea as said.
<br>template <class EC>
<br>requires Same<EC, error_code> or =C2=A0Same<EC, filesystem::fi=
lesystem_error>
<br>expected<X, EC> filesystem::function(...);
<br>
<br>=C2=A0 =C2=A0 =C2=A0auto x =3D filesystem::function<error_<wbr>code&=
gt;(...);
<br>or
<br>=C2=A0 =C2=A0 =C2=A0auto x =3D filesystem::function<<wbr>filesystem:=
:filesystem_error>(<wbr>...);
<br>
<br>The filesystem function know at compile time which kind of error must b=
e=20
<br>reported and could at compile time build it without any performance pen=
alty.<br></blockquote><div><br>OK, that's a design. It provides zero ov=
erhead for local handlers. Though it does cause some overhead for non-local=
handlers; the `filesystem_error` has to be constructed, then copied into t=
he actual exception.<br><br>So, what does the implementation of, for exampl=
e `file_size` look like? Well, it would look something like this:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> EC</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//Insert various machinery to SFINAE ensure=
EC's types.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>expected</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><uintmax</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> EC</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> file_size</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">path p</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> sz </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//get ac=
tual file size.</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">/*did error=
*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">ConstructError</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">EC</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify">"filesystem::file_size"</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">/*Get error code*/</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"></span></code>);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> sz</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><br>Where `ConstructError<EC>`=
constructs an `unexpected_type<EC>`, using different logic based on =
whether EC was an error_code or a filesystem_error. There would be differen=
t overloads of `ConstructError` for the different `filesystem_error` constr=
uctor variants.<br><br>After looking at Boost.FileSystem, this doesn't =
seem like much of a difference compared to the way they implement error han=
dling. They have one primary implementation function that takes an error_co=
de by pointer, which throws if the pointer is NULL. The actual API function=
s are all just one-liners in the header, which call the main function with =
a null or non-null pointer.<br><br>Oh, and something I realized while writi=
ng this. Above, I said that the filesystem_error has to be copied into the =
exception. Well, the user ought to have some say in that, since copying tak=
es up precious performance. I would suggest having an overload of `value` b=
ased on & and && `this` qualifiers:<br><br>const T &value()=
const &;<br>T value() &&;<br><br>In the first case, it will re=
turn a reference to T or throw a copy of E (or whatever the customization m=
echanism deduces to). In the second case, it returns a move-constructed T o=
r throws a <i>move-constructed</i> E (via something like `throw std::move(s=
td::move(*this).error())`.<br><br>The point of this is to allow for the use=
r to do this:<br><br>uintmax_t size =3D fs::file_size(p).value();<br><br>Be=
cause the return value is an prvalue, it should call the && overloa=
d of `value`. That will move T out (which is just a copy), but in the event=
of an exception, it will move-construct the exception object from the `fil=
esystem_error`. That will help minimize the overhead to exception users. It=
will also help minimize the chance of throwing an exception during the con=
struction of the exception object (path, for example, is nothrow moveable).=
<br><br>Of course, this also means that whatever exception customization me=
chanism you come up with will need to allow for similar forwarding of move =
intent.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
EC can have even be defaulted.
<br>
<br>=C2=A0 =C2=A0 =C2=A0auto x =3D filesystem::function(...);
<br>
<br>
<br>
<br>>> If it is not possible to develop such a way, to have a single =
function
<br>>> provide both local and non-local exceptions without overloadin=
g, then I
<br>>> submit that there is no reason to give `value` customized exce=
ptions.=20
<br>>> Since
<br>>> that seemed to be the primary motivation, if it's not poss=
ible, then it
<br>>> seems to me that there is no motivation for this feature.
<br>> I give other useful customization cases.
<br>>>
<br>>> It seems to me that there are two outstanding questions:
<br>>>
<br>>> 1) Is there an effective means to have one function, based on=
=20
<br>>> `expected`,
<br>>> which services the needs of local and non-local error handling=
just=20
<br>>> as well
<br>>> as having two overloads? Is there a fleshed-out design for suc=
h an
<br>>> interface?
<br>> It depends if people want to find a solution or not. IMHO, nobody =
has=20
<br>> spent enough time to presented a proposal on how to use expected f=
or=20
<br>> FileSystem TS.
<br>>>
<br>>> 2) What do you need to be able to do that requires `value` to =
throw
<br>>> customized exceptions? And again, don't just say "I w=
ant `expected<T,
<br>>> variant<E1, E2,...>>` to throw the particular error i=
n the variant." You
<br>>> need to explain *why* you need `value` to do that. Explain wha=
t you are
<br>>> trying to do that makes this behavior important.
<br>>>
<br>> I want expected<T, variant<E1, ...>> to throw the part=
icular error in=20
<br>> the variant :)
<br>> Why? Because a function can have several kind of errors.
<br>> E.g. expected<T, variant<error_code, filesystem_error>>=
;
<br>>
<br>Sorry, this should not work for FileSystem, as the user need to state=
=20
<br>which kind of error she wants.
<br>
<br>Anyway, you see what I mean. If now a function can throw exceptions E1,=
=20
<br>..., En, transforming it to expected would result in expected<T,=20
<br>variant<E1, ..., En>> and the less surprising exception to thr=
ow when=20
<br>value is called is IMO Ei.<br></blockquote><div><br>If you have an API =
that throws, merely sticking those exceptions in an `expected`, even as the=
actual exception types themselves (rather than `exception_ptr`), causes bl=
oat for local error handling. That's why your FileSystem design above r=
eturns <i>different</i> error types based on the user desiring local or non=
-local handling.<br><br>So there's no reason for a user to want to take=
a function that could throw some number of exceptions and turn it into a f=
unction that is an `expected` over <i>exactly</i> those exception types. Th=
at would be a bad API, for reasons we've discussed. And therefore, this=
is not a good reason to have `value` introspect a `variant` and throw the =
individual item.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_394_1600638808.1447515437838--
------=_Part_393_297420285.1447515437837--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Sat, 14 Nov 2015 17:21:53 +0100
Raw View
This is a multi-part message in MIME format.
--------------050502040907080206050507
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Am 14.11.2015 um 15:49 schrieb Nicol Bolas:
> On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
> > OK, here is where I feel we are in the conversation.
> >
> > People seem to want `value` to throw different, customization
> exceptions.
> > And as far as I can tell, the main (or only) reason to do so is
> to allow
> > people to write a single API function, which uses exceptions
> based on how
> > the return value is used. This would achieving the effect of
> FileSystem
> > TS's design, but without multiple overloads.
> >
> > I've demonstrated that a straightforward implementation of this
> is not
> > viable. It will result in either local try/catch blocks just to
> handle
> > simple error codes and lots of redundant data, or non-local
> functions will
> > not have enough information to fully resolve the error. There
> does not seem
> > to be a middle way; one side or the other always seems to lose.
> Hmm, I believe you demonstrated that expected<T,exception_ptr> is
> not a
> good candidate to manage local recovery.
> expected<T,filesystem_error> should be a better candidate.
>
>
> You will recall that one of my arguments was about bloat.=20
> `filesystem_error` contains up to two `path` objects, which given=20
> small string optimization and its error_code make the resulting=20
> `filesystem_error` object take up /at least/ 40 bytes (16 per `path`,=20
> + 8 for the error code). That doesn't even count the vtable pointer=20
> (since it's derived from `std::exception`.
>
> That's not to mention the overhead of passing back a path that the=20
> local context already has. Which may mean allocating memory, depending=20
> on the path's length.
Does the size of the exception object really matter in practice? I=20
believe we can all agree that *if* an exception is thrown any=20
performance considerations are out the window. The size of the exception=20
object only really matters in bad_alloc situations which the standard=20
library has to worry about.
>
> This improves on the original only in that you don't have to throw the=20
> exception in order to introspect it. But you are still creating=20
> needless overhead for local error handling users. It's biased towards=20
> those using exceptions.
Allocation has to happen in both cases for user defined types.=20
expected<> has an advantage here because it isn't dragged down by the=20
throw machinery. The "needless" overhead is pretty much mandatory.
>
> Oh, and I believe you said this on another thread:
>
> > If E means Error, we can not throw another error while copying it.
>
> If we are to follow that requirement, then you /cannot /embed `path`=20
> objects in the return value either, for the same reason you can't use=20
> `std::string`. Both of them have throwing copy operations (but they=20
> are no-throw moveable). So filesystem_error couldn't be used.
Of course you can. Proven by the simple fact people already use and=20
throw filesystem_error. As long as the copy doesn't *actually* fail=20
everything's fine. *If* the copy fails do as a throw would and simply=20
terminate since the two mechanisms are analogous.
>
> This requirement would also mean that you couldn't put a lot of=20
> flavorful error types into the object. That's fine for simple error=20
> codes and the like. But not for the kinds of objects that are=20
> appropriate for exceptions.
>
> So by your own design ideas, what you suggested is forbidden.
>
> I suggest to start a specific thread for how expected can improve
> FileSystem TS interface (if any), independently of whether there
> are two
> overload or only one.
>
>
> FileSystem is relevant to this thread because APIs like it are the=20
> primary motivation for wanting expected to have customized exceptions=20
> on `value`.
>
> Every reason people want this customization ultimately boils down to=20
> "I want a function to support local and non-local errors with only one=20
> overload." That's why the FileSystem TS interface is important; it's a=20
> perfect use case to prove that your customization design is=20
> functional. If a particular customization design can't solve the=20
> FileSystem TS issue adequately, then it's clear that this particular=20
> customization design isn't going to actually solve the problem at all.
>
> So the best way to judge any suggested customization mechanism is to=20
> judge it by whether it solves the problem that people want it to=20
> solve. And FileSystem is an excellent example of that problem.
>
> >
> > Vicente put forth a sketch of an idea for unifying such APIs.
> But the idea
> > lacked any real details, so it's not clear if it would actually
> resolve the
> > problem.
> Right, it is an idea as said.
> > If it is not possible to develop such a way, to have a single
> function
> > provide both local and non-local exceptions without overloading,
> then I
> > submit that there is no reason to give `value` customized
> exceptions. Since
> > that seemed to be the primary motivation, if it's not possible,
> then it
> > seems to me that there is no motivation for this feature.
> I give other useful customization cases.
>
>
> No, you stated the behavior you wanted to customize. You didn't say=20
> why you wanted to do it. That would be the motivation part.
>
> >
> > It seems to me that there are two outstanding questions:
> >
> > 1) Is there an effective means to have one function, based on
> `expected`,
> > which services the needs of local and non-local error handling
> just as well
> > as having two overloads? Is there a fleshed-out design for such an
> > interface?
> It depends if people want to find a solution or not. IMHO, nobody has
> spent enough time to presented a proposal on how to use expected for
> FileSystem TS.
> >
> > 2) What do you need to be able to do that requires `value` to throw
> > customized exceptions? And again, don't just say "I want
> `expected<T,
> > variant<E1, E2,...>>` to throw the particular error in the
> variant." You
> > need to explain *why* you need `value` to do that. Explain what
> you are
> > trying to do that makes this behavior important.
> >
> I want expected<T, variant<E1, ...>> to throw the particular error in
> the variant :)
> Why? Because a function can have several kind of errors.
> E.g. expected<T, variant<error_code, filesystem_error>>
>
>
> Some time ago I suggested a variadic version of expected
> expected<T, error_code, filesystem_error>=20
>
>
> This gives you local and non-local error reporting tool.
>
>
> This is better for local error handling, since you're not passing back=20
> data that the local context already has. But it still causes bloat to=20
> the size of `expected`.
>
> It also makes such a multi-variant becomes a /lot/ more difficult to=20
> work with. I'm pretty sure you'd lose your precious `await`=20
> propagation, since `await` has no way of knowing which error to fetch,=20
> which has to be a /compile-time/ selection of a /runtime-defined/=20
> value. Even visitation wouldn't work, since you can't return different=20
> types.
>
> This design also forces people to use an awkward `std::get`-style=20
> interface to get the particular error out, as opposed to the much=20
> simpler `.error`.
>
> This is what we would call "scope creep". It comes from having a poor=20
> vision of the overall design for the type, from trying to make a type=20
> that solves /everyone's/ problems. It tends to end up with a type that=20
> solves everyone's problems, but does so very sub-optimally.
>
> My vision of `expected` is this: it's for local/non-throwing error=20
> handling. To that end, it should be as simple to use as possible, with=20
> a clear and obvious API and minimal overhead.
>
> Multiple error types are not useful for local handling; having=20
> multiple error types is useful only for two cases. 1) Single-function=20
> local and non-local error handling, as in your case above. And 2) the=20
> ability to propagate errors out of a function from multiple `expected`=20
> sources. Well, if `expected` is for local handling, its ability to=20
> propagate errors is irrelevant (you don't propagate errors if you're=20
> handling them locally). So too is its ability to allow single-function=20
> non-local error handling.
>
> I would much rather have `expected<T, E>`, which is simple and easy to=20
> use. If you want to use `expected` outside of local error handling,=20
> then its interface will become increasingly more complicated. Keep the=20
> main class simple to use. So people who want to use the type against=20
> its purpose should have to do `expected<T, variant<E1, E2, ...>>`=20
> explicitly. Yes, that's a lot harder to use, but you would only use it=20
> when you're using `expected` for something that `expected` isn't=20
> really meant to do.
>
> That you could
> prefer two overloaded function is another matter.
>
> Vicente
>
> P.S. Don't forget we a constructing an expected proposal, that
> respond
> to the user needs (and the standard library can be a user).
>
> P.S.S. expected proposal has a visitation interface
>
>
> A visitation interface would only be reasonable for `expected` if it=20
> allowed multiple error types natively. Otherwise, nobody would use it.=20
> And even then, you would only visit it for the errors within it.
> --=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>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------050502040907080206050507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 14.11.2015 um 15:49 schrieb Nicol Bolas:<br>
<blockquote
cite=3D"mid:b4574ee0-585a-4620-8903-d7412c027693@isocpp.org"
type=3D"cite">On Saturday, November 14, 2015 at 3:54:08 AM UTC-5,
Vicente J. Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
<br>
> OK, here is where I feel we are in the conversation.
<br>
>
<br>
> People seem to want `value` to throw different,
customization exceptions.
<br>
> And as far as I can tell, the main (or only) reason to do
so is to allow
<br>
> people to write a single API function, which uses
exceptions based on how
<br>
> the return value is used. This would achieving the effect
of FileSystem
<br>
> TS's design, but without multiple overloads.
<br>
>
<br>
> I've demonstrated that a straightforward implementation of
this is not
<br>
> viable. It will result in either local try/catch blocks
just to handle
<br>
> simple error codes and lots of redundant data, or non-local
functions will
<br>
> not have enough information to fully resolve the error.
There does not seem
<br>
> to be a middle way; one side or the other always seems to
lose.
<br>
Hmm, I believe you demonstrated that
expected<T,exception_ptr> is not a <br>
good candidate to manage local recovery.
<br>
expected<T,filesystem_error> should be a better candidate.<br=
>
</blockquote>
<div><br>
You will recall that one of my arguments was about bloat.
`filesystem_error` contains up to two `path` objects, which
given small string optimization and its error_code make the
resulting `filesystem_error` object take up <i>at least</i> 40
bytes (16 per `path`, + 8 for the error code). That doesn't even
count the vtable pointer (since it's derived from
`std::exception`.<br>
<br>
That's not to mention the overhead of passing back a path that
the local context already has. Which may mean allocating memory,
depending on the path's length.<br>
</div>
</blockquote>
Does the size of the exception object really matter in practice? I
believe we can all agree that *if* an exception is thrown any
performance considerations are out the window. The size of the
exception object only really matters in bad_alloc situations which
the standard library has to worry about.<br>
<blockquote
cite=3D"mid:b4574ee0-585a-4620-8903-d7412c027693@isocpp.org"
type=3D"cite">
<div><br>
This improves on the original only in that you don't have to
throw the exception in order to introspect it. But you are still
creating needless overhead for local error handling users. It's
biased towards those using exceptions.<br>
</div>
</blockquote>
Allocation has to happen in both cases for user defined types.
expected<> has an advantage here because it isn't dragged down
by the throw machinery. The "needless" overhead is pretty much
mandatory.<br>
<blockquote
cite=3D"mid:b4574ee0-585a-4620-8903-d7412c027693@isocpp.org"
type=3D"cite">
<div><br>
Oh, and I believe you said this on another thread:<br>
<br>
> If E means Error, we can not throw another error while
copying it.<br>
<br>
If we are to follow that requirement, then you <i>cannot </i>embed
`path` objects in the return value either, for the same reason
you can't use `std::string`. Both of them have throwing copy
operations (but they are no-throw moveable). So filesystem_error
couldn't be used.<br>
</div>
</blockquote>
Of course you can. Proven by the simple fact people already use and
throw filesystem_error. As long as the copy doesn't *actually* fail
everything's fine. *If* the copy fails do as a throw would and
simply terminate since the two mechanisms are analogous.<br>
<blockquote
cite=3D"mid:b4574ee0-585a-4620-8903-d7412c027693@isocpp.org"
type=3D"cite">
<div><br>
This requirement would also mean that you couldn't put a lot of
flavorful error types into the object. That's fine for simple
error codes and the like. But not for the kinds of objects that
are appropriate for exceptions.<br>
<br>
So by your own design ideas, what you suggested is forbidden.<br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
I suggest to start a specific thread for how expected can
improve <br>
FileSystem TS interface (if any), independently of whether there
are two <br>
overload or only one.<br>
</blockquote>
<div><br>
FileSystem is relevant to this thread because APIs like it are
the primary motivation for wanting expected to have customized
exceptions on `value`.<br>
<br>
Every reason people want this customization ultimately boils
down to "I want a function to support local and non-local errors
with only one overload." That's why the FileSystem TS interface
is important; it's a perfect use case to prove that your
customization design is functional. If a particular
customization design can't solve the FileSystem TS issue
adequately, then it's clear that this particular customization
design isn't going to actually solve the problem at all.<br>
<br>
So the best way to judge any suggested customization mechanism
is to judge it by whether it solves the problem that people want
it to solve. And FileSystem is an excellent example of that
problem.<br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>
> Vicente put forth a sketch of an idea for unifying such
APIs. But the idea
<br>
> lacked any real details, so it's not clear if it would
actually resolve the
<br>
> problem.
<br>
Right, it is an idea as said.
<br>
> If it is not possible to develop such a way, to have a
single function
<br>
> provide both local and non-local exceptions without
overloading, then I
<br>
> submit that there is no reason to give `value` customized
exceptions. Since
<br>
> that seemed to be the primary motivation, if it's not
possible, then it
<br>
> seems to me that there is no motivation for this feature.
<br>
I give other useful customization cases.<br>
</blockquote>
<div><br>
No, you stated the behavior you wanted to customize. You didn't
say why you wanted to do it. That would be the motivation part.<br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>
> It seems to me that there are two outstanding questions:
<br>
>
<br>
> 1) Is there an effective means to have one function, based
on `expected`,
<br>
> which services the needs of local and non-local error
handling just as well
<br>
> as having two overloads? Is there a fleshed-out design for
such an
<br>
> interface?
<br>
It depends if people want to find a solution or not. IMHO,
nobody has <br>
spent enough time to presented a proposal on how to use expected
for <br>
FileSystem TS.
<br>
>
<br>
> 2) What do you need to be able to do that requires `value`
to throw
<br>
> customized exceptions? And again, don't just say "I want
`expected<T,
<br>
> variant<E1, E2,...>>` to throw the particular
error in the variant." You
<br>
> need to explain *why* you need `value` to do that. Explain
what you are
<br>
> trying to do that makes this behavior important.
<br>
>
<br>
I want expected<T, variant<E1, ...>> to throw the
particular error in <br>
the variant :)
<br>
Why? Because a function can have several kind of errors.
<br>
E.g. expected<T, variant<error_code,
filesystem_error>>
<br>
<br>
<br>
Some time ago I suggested a variadic version of expected
<br>
expected<T, error_code, filesystem_error>=C2=A0</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>
This gives you local and non-local error reporting tool.</blockquot=
e>
<div><br>
This is better for local error handling, since you're not
passing back data that the local context already has. But it
still causes bloat to the size of `expected`.<br>
<br>
It also makes such a multi-variant becomes a <i>lot</i> more
difficult to work with. I'm pretty sure you'd lose your precious
`await` propagation, since `await` has no way of knowing which
error to fetch, which has to be a <i>compile-time</i> selection
of a <i>runtime-defined</i> value. Even visitation wouldn't
work, since you can't return different types.<br>
<br>
This design also forces people to use an awkward
`std::get`-style interface to get the particular error out, as
opposed to the much simpler `.error`.<br>
<br>
This is what we would call "scope creep". It comes from having a
poor vision of the overall design for the type, from trying to
make a type that solves <i>everyone's</i> problems. It tends to
end up with a type that solves everyone's problems, but does so
very sub-optimally.<br>
<br>
My vision of `expected` is this: it's for local/non-throwing
error handling. To that end, it should be as simple to use as
possible, with a clear and obvious API and minimal overhead.<br>
<br>
Multiple error types are not useful for local handling; having
multiple error types is useful only for two cases. 1)
Single-function local and non-local error handling, as in your
case above. And 2) the ability to propagate errors out of a
function from multiple `expected` sources. Well, if `expected`
is for local handling, its ability to propagate errors is
irrelevant (you don't propagate errors if you're handling them
locally). So too is its ability to allow single-function
non-local error handling.<br>
<br>
I would much rather have `expected<T, E>`, which is simple
and easy to use. If you want to use `expected` outside of local
error handling, then its interface will become increasingly more
complicated. Keep the main class simple to use. So people who
want to use the type against its purpose should have to do
`expected<T, variant<E1, E2, ...>>` explicitly. Yes,
that's a lot harder to use, but you would only use it when
you're using `expected` for something that `expected` isn't
really meant to do.<br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> That you
could <br>
prefer two overloaded function is another matter.
<br>
<br>
Vicente
<br>
<br>
P.S. Don't forget we a constructing an expected proposal, that
respond <br>
to the user needs (and the standard library can be a user).
<br>
<br>
P.S.S. expected proposal has a visitation interface
<br>
</blockquote>
<div><br>
A visitation interface would only be reasonable for `expected`
if it allowed multiple error types natively. Otherwise, nobody
would use it. And even then, you would only visit it for the
errors within it.<br>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------050502040907080206050507--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 09:38:31 -0800 (PST)
Raw View
------=_Part_219_204041711.1447522711179
Content-Type: multipart/alternative;
boundary="----=_Part_220_300909149.1447522711179"
------=_Part_220_300909149.1447522711179
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 11:21:09 AM UTC-5, Miro Knejp wrote:
>
> Am 14.11.2015 um 15:49 schrieb Nicol Bolas:
>
> On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J. Botet=20
> Escriba wrote:=20
>>
>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :=20
>> > OK, here is where I feel we are in the conversation.=20
>> >=20
>> > People seem to want `value` to throw different, customization=20
>> exceptions.=20
>> > And as far as I can tell, the main (or only) reason to do so is to=20
>> allow=20
>> > people to write a single API function, which uses exceptions based on=
=20
>> how=20
>> > the return value is used. This would achieving the effect of FileSyste=
m=20
>> > TS's design, but without multiple overloads.=20
>> >=20
>> > I've demonstrated that a straightforward implementation of this is not=
=20
>> > viable. It will result in either local try/catch blocks just to handle=
=20
>> > simple error codes and lots of redundant data, or non-local functions=
=20
>> will=20
>> > not have enough information to fully resolve the error. There does not=
=20
>> seem=20
>> > to be a middle way; one side or the other always seems to lose.=20
>> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not a=
=20
>> good candidate to manage local recovery.=20
>> expected<T,filesystem_error> should be a better candidate.
>>
>
> You will recall that one of my arguments was about bloat.=20
> `filesystem_error` contains up to two `path` objects, which given small=
=20
> string optimization and its error_code make the resulting=20
> `filesystem_error` object take up *at least* 40 bytes (16 per `path`, + 8=
=20
> for the error code). That doesn't even count the vtable pointer (since it=
's=20
> derived from `std::exception`.
>
> That's not to mention the overhead of passing back a path that the local=
=20
> context already has. Which may mean allocating memory, depending on the=
=20
> path's length.
>
> Does the size of the exception object really matter in practice? I believ=
e=20
> we can all agree that *if* an exception is thrown any performance=20
> considerations are out the window. The size of the exception object only=
=20
> really matters in bad_alloc situations which the standard library has to=
=20
> worry about.
>
Yeah, kinda. Not just the size of the expected (people can be very picky=20
about stack space. See discussions about `variant` double-buffering for an=
=20
example), but also the allocation of memory.
Remember: many users of `expected` operate in contexts where exceptions=20
simply aren't allowed. And most of those contexts *also* forbid random=20
memory allocations. So they would be unable to use `expected` with error=20
objects that allocate memory. Especially if there were no way to provide an=
=20
allocator or some other allocation control.
And let's not forget that the space taken up will not be used for local=20
error handling. Local error handling is *only* interested in the error=20
code, not the paths or string message.
>
> This improves on the original only in that you don't have to throw the=20
> exception in order to introspect it. But you are still creating needless=
=20
> overhead for local error handling users. It's biased towards those using=
=20
> exceptions.
>
> Allocation has to happen in both cases for user defined types. expected<>=
=20
> has an advantage here because it isn't dragged down by the throw machiner=
y.=20
> The "needless" overhead is pretty much mandatory.
>
This has already been discussed, and no it is not mandatory. Not if you=20
want to handle the error locally. The path object(s) in the=20
`filesystem_error` are data that the local context *already has*. So it=20
doesn't need them delivered back to them. It only makes sense to provide=20
that data if you're doing non-local error handling.
This is why FileSystem doesn't have an interface that fills in a=20
`filesystem_error` by reference. It takes `error_code` by reference,=20
because that's the minimum information that the local context needs.
Locally, all you want is an error_code. Only for non-local handling do you=
=20
want a full `filesystem_error`.
=20
>
> Oh, and I believe you said this on another thread:
>
> > If E means Error, we can not throw another error while copying it.
>
> If we are to follow that requirement, then you *cannot *embed `path`=20
> objects in the return value either, for the same reason you can't use=20
> `std::string`. Both of them have throwing copy operations (but they are=
=20
> no-throw moveable). So filesystem_error couldn't be used.
>
> Of course you can. Proven by the simple fact people already use and throw=
=20
> filesystem_error. As long as the copy doesn't *actually* fail everything'=
s=20
> fine. *If* the copy fails do as a throw would and simply terminate since=
=20
> the two mechanisms are analogous.
>
I said "if we are to follow that requirement;" that should not be taken as=
=20
an *endorsement* of said requirement. Obviously `filesystem_error` is a=20
perfectly functional exception type. My point was that he was talking=20
elsewhere about adding requirements to `expected` that he hadn't realized=
=20
would *forbid* the use of `expected<T, filesystem_error>`.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_220_300909149.1447522711179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 11:21:09 AM UTC-5, Miro Knejp wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 14.11.2015 um 15:49 schrieb Nicol Bolas:<br>
<blockquote type=3D"cite">On Saturday, November 14, 2015 at 3:54:08 AM =
UTC-5,
Vicente J. Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">Le
14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
<br>
> OK, here is where I feel we are in the conversation.
<br>
>
<br>
> People seem to want `value` to throw different,
customization exceptions.
<br>
> And as far as I can tell, the main (or only) reason to do
so is to allow
<br>
> people to write a single API function, which uses
exceptions based on how
<br>
> the return value is used. This would achieving the effect
of FileSystem
<br>
> TS's design, but without multiple overloads.
<br>
>
<br>
> I've demonstrated that a straightforward implementation of
this is not
<br>
> viable. It will result in either local try/catch blocks
just to handle
<br>
> simple error codes and lots of redundant data, or non-local
functions will
<br>
> not have enough information to fully resolve the error.
There does not seem
<br>
> to be a middle way; one side or the other always seems to
lose.
<br>
Hmm, I believe you demonstrated that
expected<T,exception_ptr> is not a <br>
good candidate to manage local recovery.
<br>
expected<T,filesystem_error> should be a better candidate.<br=
>
</blockquote>
<div><br>
You will recall that one of my arguments was about bloat.
`filesystem_error` contains up to two `path` objects, which
given small string optimization and its error_code make the
resulting `filesystem_error` object take up <i>at least</i> 40
bytes (16 per `path`, + 8 for the error code). That doesn't eve=
n
count the vtable pointer (since it's derived from
`std::exception`.<br>
<br>
That's not to mention the overhead of passing back a path that
the local context already has. Which may mean allocating memory,
depending on the path's length.<br>
</div>
</blockquote>
Does the size of the exception object really matter in practice? I
believe we can all agree that *if* an exception is thrown any
performance considerations are out the window. The size of the
exception object only really matters in bad_alloc situations which
the standard library has to worry about.<br></div></blockquote><div><br=
>Yeah, kinda. Not just the size of the expected (people can be very picky a=
bout stack space. See discussions about `variant` double-buffering for an e=
xample), but also the allocation of memory.<br><br>Remember: many users of =
`expected` operate in contexts where exceptions simply aren't allowed. =
And most of those contexts <i>also</i> forbid random memory allocations. So=
they would be unable to use `expected` with error objects that allocate me=
mory. Especially if there were no way to provide an allocator or some other=
allocation control.<br><br>And let's not forget that the space taken u=
p will not be used for local error handling. Local error handling is <i>onl=
y</i> interested in the error code, not the paths or string message.<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" te=
xt=3D"#000000">
<blockquote type=3D"cite">
<div><br>
This improves on the original only in that you don't have to
throw the exception in order to introspect it. But you are still
creating needless overhead for local error handling users. It's
biased towards those using exceptions.<br>
</div>
</blockquote>
Allocation has to happen in both cases for user defined types.
expected<> has an advantage here because it isn't dragged dow=
n
by the throw machinery. The "needless" overhead is pretty muc=
h
mandatory.<br></div></blockquote><div><br>This has already been discuss=
ed, and no it is not mandatory. Not if you want to handle the error locally=
.. The path object(s) in the `filesystem_error` are data that the local cont=
ext <i>already has</i>. So it doesn't need them delivered back to them.=
It only makes sense to provide that data if you're doing non-local err=
or handling.<br><br>This is why FileSystem doesn't have an interface th=
at fills in a `filesystem_error` by reference. It takes `error_code` by ref=
erence, because that's the minimum information that the local context n=
eeds.<br><br>Locally, all you want is an error_code. Only for non-local han=
dling do you want a full `filesystem_error`.<br>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div><br>
Oh, and I believe you said this on another thread:<br>
<br>
> If E means Error, we can not throw another error while
copying it.<br>
<br>
If we are to follow that requirement, then you <i>cannot </i>embed
`path` objects in the return value either, for the same reason
you can't use `std::string`. Both of them have throwing copy
operations (but they are no-throw moveable). So filesystem_error
couldn't be used.<br>
</div>
</blockquote>
Of course you can. Proven by the simple fact people already use and
throw filesystem_error. As long as the copy doesn't *actually* fail
everything's fine. *If* the copy fails do as a throw would and
simply terminate since the two mechanisms are analogous.<br></div></blo=
ckquote><div><br>I said "if we are to follow that requirement;" t=
hat should not be taken as an <i>endorsement</i> of said requirement. Obvio=
usly `filesystem_error` is a perfectly functional exception type. My point =
was that he was talking elsewhere about adding requirements to `expected` t=
hat he hadn't realized would <i>forbid</i> the use of `expected<T, f=
ilesystem_error>`.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_220_300909149.1447522711179--
------=_Part_219_204041711.1447522711179--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 14 Nov 2015 18:41:21 +0100
Raw View
Le 14/11/2015 16:37, Nicol Bolas a =C3=A9crit :
> On Saturday, November 14, 2015 at 4:33:48 AM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Le 14/11/2015 09:54, Vicente J. Botet Escriba a =C3=A9crit :
>>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
>>>> OK, here is where I feel we are in the conversation.
>>>>
>>>> People seem to want `value` to throw different, customization
>>>> exceptions.
>>>> And as far as I can tell, the main (or only) reason to do so is to
>> allow
>>>> people to write a single API function, which uses exceptions based on
>>>> how
>>>> the return value is used. This would achieving the effect of FileSyste=
m
>>>> TS's design, but without multiple overloads.
>>>>
>>>> I've demonstrated that a straightforward implementation of this is not
>>>> viable. It will result in either local try/catch blocks just to handle
>>>> simple error codes and lots of redundant data, or non-local functions
>>>> will
>>>> not have enough information to fully resolve the error. There does
>>>> not seem
>>>> to be a middle way; one side or the other always seems to lose.
>>> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not
>>> a good candidate to manage local recovery.
>>> expected<T,filesystem_error> should be a better candidate.
>>>
>>> I suggest to start a specific thread for how expected can improve
>>> FileSystem TS interface (if any), independently of whether there are
>>> two overload or only one.
>>>> Vicente put forth a sketch of an idea for unifying such APIs. But the
>>>> idea
>>>> lacked any real details, so it's not clear if it would actually
>>>> resolve the
>>>> problem.
>>> Right, it is an idea as said.
>> template <class EC>
>> requires Same<EC, error_code> or Same<EC, filesystem::filesystem_error>
>> expected<X, EC> filesystem::function(...);
>>
>> auto x =3D filesystem::function<error_code>(...);
>> or
>> auto x =3D filesystem::function<filesystem::filesystem_error>(...)=
;
>>
>> The filesystem function know at compile time which kind of error must be
>> reported and could at compile time build it without any performance
>> penalty.
>>
> OK, that's a design. It provides zero overhead for local handlers. Though
> it does cause some overhead for non-local handlers; the `filesystem_error=
`
> has to be constructed, then copied into the actual exception.
It can be constructed in place.
>
> So, what does the implementation of, for example `file_size` look like?
> Well, it would look something like this:
>
> template<typename EC>
> //Insert various machinery to SFINAE ensure EC's types.
> expected<uintmax_t, EC> file_size(path p)
> {
> auto sz =3D //get actual file size.
> if(/*did error*/)
> {
> return ConstructError<EC>("filesystem::file_size", p, /*Get error co=
de*/
> );
> }
>
> return sz;
> }
>
> Where `ConstructError<EC>` constructs an `unexpected_type<EC>`, using
> different logic based on whether EC was an error_code or a
> filesystem_error. There would be different overloads of `ConstructError`
> for the different `filesystem_error` constructor variants.
>
> After looking at Boost.FileSystem, this doesn't seem like much of a
> difference compared to the way they implement error handling. They have o=
ne
> primary implementation function that takes an error_code by pointer, whic=
h
> throws if the pointer is NULL. The actual API functions are all just
> one-liners in the header, which call the main function with a null or
> non-null pointer.
>
> Oh, and something I realized while writing this. Above, I said that the
> filesystem_error has to be copied into the exception. Well, the user ough=
t
> to have some say in that, since copying takes up precious performance. I
> would suggest having an overload of `value` based on & and && `this`
> qualifiers:
>
> const T &value() const &;
> T value() &&;
They are already in my implementation. I don't think they are in the=20
proposal. This was introduced in optional later on.
> In the first case, it will return a reference to T or throw a copy of E (=
or
> whatever the customization mechanism deduces to). In the second case, it
> returns a move-constructed T or throws a *move-constructed* E (via
> something like `throw std::move(std::move(*this).error())`.
>
> The point of this is to allow for the user to do this:
>
> uintmax_t size =3D fs::file_size(p).value();
>
> Because the return value is an prvalue, it should call the && overload of
> `value`. That will move T out (which is just a copy), but in the event of
> an exception, it will move-construct the exception object from the
> `filesystem_error`. That will help minimize the overhead to exception
> users. It will also help minimize the chance of throwing an exception
> during the construction of the exception object (path, for example, is
> nothrow moveable).
>
> Of course, this also means that whatever exception customization mechanis=
m
> you come up with will need to allow for similar forwarding of move intent=
..
>
> EC can have even be defaulted.
>> auto x =3D filesystem::function(...);
>>
>>
>>
>>>> If it is not possible to develop such a way, to have a single function
>>>> provide both local and non-local exceptions without overloading, then =
I
>>>> submit that there is no reason to give `value` customized exceptions.
>>>> Since
>>>> that seemed to be the primary motivation, if it's not possible, then i=
t
>>>> seems to me that there is no motivation for this feature.
>>> I give other useful customization cases.
>>>> It seems to me that there are two outstanding questions:
>>>>
>>>> 1) Is there an effective means to have one function, based on
>>>> `expected`,
>>>> which services the needs of local and non-local error handling just
>>>> as well
>>>> as having two overloads? Is there a fleshed-out design for such an
>>>> interface?
>>> It depends if people want to find a solution or not. IMHO, nobody has
>>> spent enough time to presented a proposal on how to use expected for
>>> FileSystem TS.
>>>> 2) What do you need to be able to do that requires `value` to throw
>>>> customized exceptions? And again, don't just say "I want `expected<T,
>>>> variant<E1, E2,...>>` to throw the particular error in the variant."
>> You
>>>> need to explain *why* you need `value` to do that. Explain what you ar=
e
>>>> trying to do that makes this behavior important.
>>>>
>>> I want expected<T, variant<E1, ...>> to throw the particular error in
>>> the variant :)
>>> Why? Because a function can have several kind of errors.
>>> E.g. expected<T, variant<error_code, filesystem_error>>
>>>
>> Sorry, this should not work for FileSystem, as the user need to state
>> which kind of error she wants.
>>
>> Anyway, you see what I mean. If now a function can throw exceptions E1,
>> ..., En, transforming it to expected would result in expected<T,
>> variant<E1, ..., En>> and the less surprising exception to throw when
>> value is called is IMO Ei.
>>
> If you have an API that throws, merely sticking those exceptions in an
> `expected`, even as the actual exception types themselves (rather than
> `exception_ptr`), causes bloat for local error handling.
We surely are not talking of the same thing. IMO it is the opposite, it=20
helps to manage local errors.
The case for having a variant could be to have specific filesystem_error=20
classes each one with the data needed. It is not to make the difference=20
between local and non-local error handling. For example instead of just=20
one exception class you could have 3. No path, 1 path 2 paths.
> That's why your
> FileSystem design above returns *different* error types based on the user
> desiring local or non-local handling.
Do you think that all the APIs need to select between local and=20
non-local handling?
I don't master the FileSystem TS. IIUC the exception throw has an=20
error_code and possibly two paths that should appear in the call, isn't=20
it? If this is correct, what would be the advantage to returning=20
expected<T, filesystem_error> over expected<T, error_code>?
With expected<T,error_code> the user can add anything she considers=20
useful while propagating the error.
If we had
expected<T,error_code> fs::file_size(const path&);
the user could transform the local handling into a non-local handling=20
adding the path as follows
auto x =3D fs::file_size(p).catch_error(wrap_with_path(p)).value();
when wrap_with_path will construct an error that contains the error code=20
and the path.
This design will need only one overload, which will simplify the TS=20
implementation. From the user side the code could be more complex, but=20
the user master what is propagated.
>
> So there's no reason for a user to want to take a function that could thr=
ow
> some number of exceptions and turn it into a function that is an `expecte=
d`
> over *exactly* those exception types. That would be a bad API, for reason=
s
> we've discussed. And therefore, this is not a good reason to have `value`
> introspect a `variant` and throw the individual item.
>
Yes there is, because even when I request an error_code I could expect a=20
system_error to be thrown by default.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Sat, 14 Nov 2015 19:14:42 +0100
Raw View
This is a multi-part message in MIME format.
--------------050401050707060609020108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Am 14.11.2015 um 18:38 schrieb Nicol Bolas:
> On Saturday, November 14, 2015 at 11:21:09 AM UTC-5, Miro Knejp wrote:
>
> Am 14.11.2015 um 15:49 schrieb Nicol Bolas:
>> On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J.
>> Botet Escriba wrote:
>>
>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
>> > OK, here is where I feel we are in the conversation.
>> >
>> > People seem to want `value` to throw different,
>> customization exceptions.
>> > And as far as I can tell, the main (or only) reason to do
>> so is to allow
>> > people to write a single API function, which uses
>> exceptions based on how
>> > the return value is used. This would achieving the effect
>> of FileSystem
>> > TS's design, but without multiple overloads.
>> >
>> > I've demonstrated that a straightforward implementation of
>> this is not
>> > viable. It will result in either local try/catch blocks
>> just to handle
>> > simple error codes and lots of redundant data, or non-local
>> functions will
>> > not have enough information to fully resolve the error.
>> There does not seem
>> > to be a middle way; one side or the other always seems to
>> lose.
>> Hmm, I believe you demonstrated that
>> expected<T,exception_ptr> is not a
>> good candidate to manage local recovery.
>> expected<T,filesystem_error> should be a better candidate.
>>
>>
>> You will recall that one of my arguments was about bloat.
>> `filesystem_error` contains up to two `path` objects, which given
>> small string optimization and its error_code make the resulting
>> `filesystem_error` object take up /at least/ 40 bytes (16 per
>> `path`, + 8 for the error code). That doesn't even count the
>> vtable pointer (since it's derived from `std::exception`.
>>
>> That's not to mention the overhead of passing back a path that
>> the local context already has. Which may mean allocating memory,
>> depending on the path's length.
> Does the size of the exception object really matter in practice? I
> believe we can all agree that *if* an exception is thrown any
> performance considerations are out the window. The size of the
> exception object only really matters in bad_alloc situations which
> the standard library has to worry about.
>
>
> Yeah, kinda. Not just the size of the expected (people can be very=20
> picky about stack space. See discussions about `variant`=20
> double-buffering for an example), but also the allocation of memory.
>
> Remember: many users of `expected` operate in contexts where=20
> exceptions simply aren't allowed.
I'm sure you have numbers to back up this claim, as always. The original=20
motivation of expected as introduced by Alexandrescu was based around=20
expection_ptr so saying that *many* (what % is that?) don't allow=20
exceptions is pretty much useless without data.
> And most of those contexts /also/ forbid random memory allocations. So=20
> they would be unable to use `expected` with error objects that=20
> allocate memory. Especially if there were no way to provide an=20
> allocator or some other allocation control.
>
> And let's not forget that the space taken up will not be used for=20
> local error handling. Local error handling is /only/ interested in the=20
> error code, not the paths or string message.
That very much depends on the type of application and the call context.=20
Generalizations like that are rarely useful.
>
>>
>> This improves on the original only in that you don't have to
>> throw the exception in order to introspect it. But you are still
>> creating needless overhead for local error handling users. It's
>> biased towards those using exceptions.
> Allocation has to happen in both cases for user defined types.
> expected<> has an advantage here because it isn't dragged down by
> the throw machinery. The "needless" overhead is pretty much mandatory=
..
>
>
> This has already been discussed, and no it is not mandatory. Not if=20
> you want to handle the error locally. The path object(s) in the=20
> `filesystem_error` are data that the local context /already has/. So=20
> it doesn't need them delivered back to them. It only makes sense to=20
> provide that data if you're doing non-local error handling.
Depending on whether E=3Dexception_ptr in which case an allocation is=20
still required, but one is still better off than actually throwing. As=20
to motivation why one would want to capture the exception instead of=20
just propagating it see Alexandrescu's talks.
>
> This is why FileSystem doesn't have an interface that fills in a=20
> `filesystem_error` by reference. It takes `error_code` by reference,=20
> because that's the minimum information that the local context needs.
>
> Locally, all you want is an error_code. Only for non-local handling do=20
> you want a full `filesystem_error`.
What people actually "want" is, if ever, only known after the fact and=20
hard to theorize around beforehand. Again, generalizations don't help.=20
As doesn't imposing your own experience on everybody else.
>
>>
>> Oh, and I believe you said this on another thread:
>>
>> > If E means Error, we can not throw another error while copying it.
>>
>> If we are to follow that requirement, then you /cannot /embed
>> `path` objects in the return value either, for the same reason
>> you can't use `std::string`. Both of them have throwing copy
>> operations (but they are no-throw moveable). So filesystem_error
>> couldn't be used.
> Of course you can. Proven by the simple fact people already use
> and throw filesystem_error. As long as the copy doesn't *actually*
> fail everything's fine. *If* the copy fails do as a throw would
> and simply terminate since the two mechanisms are analogous.
>
>
> I said "if we are to follow that requirement;" that should not be=20
> taken as an /endorsement/ of said requirement. Obviously=20
> `filesystem_error` is a perfectly functional exception type. My point=20
> was that he was talking elsewhere about adding requirements to=20
> `expected` that he hadn't realized would /forbid/ the use of=20
> `expected<T, filesystem_error>`.)
Well, since you quoted him out of context, I'm going to reply out of=20
context as I'm not going to search for the discussion that quote came from.
"If E means Error, we can not throw another error while copying it."
This behavior matches the requirements imposed on exception types for=20
throw expressions. They don't need to be noexcept, they just aren't=20
allowed to actually throw when copied. If expected follows that pattern=20
and terminates if an exception is thrown during copy construction or=20
assignment it doesn't have stricter requirements than throw currently does.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------050401050707060609020108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 14.11.2015 um 18:38 schrieb Nicol Bolas:<br>
<blockquote
cite=3D"mid:19179fc2-61c5-4cb1-bb0a-169b0d033a8d@isocpp.org"
type=3D"cite">On Saturday, November 14, 2015 at 11:21:09 AM UTC-5,
Miro Knejp wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> Am 14.11.2015 um 15:49
schrieb Nicol Bolas:<br>
<blockquote type=3D"cite">On Saturday, November 14, 2015 at
3:54:08 AM UTC-5, Vicente J. Botet Escriba wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">Le 14/11/2015 01:38, Nicol Bolas a
=C3=A9crit : <br>
> OK, here is where I feel we are in the conversation.
<br>
> <br>
> People seem to want `value` to throw different,
customization exceptions. <br>
> And as far as I can tell, the main (or only) reason
to do so is to allow <br>
> people to write a single API function, which uses
exceptions based on how <br>
> the return value is used. This would achieving the
effect of FileSystem <br>
> TS's design, but without multiple overloads. <br>
> <br>
> I've demonstrated that a straightforward
implementation of this is not <br>
> viable. It will result in either local try/catch
blocks just to handle <br>
> simple error codes and lots of redundant data, or
non-local functions will <br>
> not have enough information to fully resolve the
error. There does not seem <br>
> to be a middle way; one side or the other always
seems to lose. <br>
Hmm, I believe you demonstrated that
expected<T,exception_ptr> is not a <br>
good candidate to manage local recovery. <br>
expected<T,filesystem_error> should be a better
candidate.<br>
</blockquote>
<div><br>
You will recall that one of my arguments was about bloat.
`filesystem_error` contains up to two `path` objects,
which given small string optimization and its error_code
make the resulting `filesystem_error` object take up <i>at
least</i> 40 bytes (16 per `path`, + 8 for the error
code). That doesn't even count the vtable pointer (since
it's derived from `std::exception`.<br>
<br>
That's not to mention the overhead of passing back a path
that the local context already has. Which may mean
allocating memory, depending on the path's length.<br>
</div>
</blockquote>
Does the size of the exception object really matter in
practice? I believe we can all agree that *if* an exception is
thrown any performance considerations are out the window. The
size of the exception object only really matters in bad_alloc
situations which the standard library has to worry about.<br>
</div>
</blockquote>
<div><br>
Yeah, kinda. Not just the size of the expected (people can be
very picky about stack space. See discussions about `variant`
double-buffering for an example), but also the allocation of
memory.<br>
<br>
Remember: many users of `expected` operate in contexts where
exceptions simply aren't allowed. </div>
</blockquote>
I'm sure you have numbers to back up this claim, as always. The
original motivation of expected as introduced by Alexandrescu was
based around expection_ptr so saying that *many* (what % is that?)
don't allow exceptions is pretty much useless without data.<br>
<blockquote
cite=3D"mid:19179fc2-61c5-4cb1-bb0a-169b0d033a8d@isocpp.org"
type=3D"cite">
<div>And most of those contexts <i>also</i> forbid random memory
allocations. So they would be unable to use `expected` with
error objects that allocate memory. Especially if there were no
way to provide an allocator or some other allocation control.<br>
<br>
And let's not forget that the space taken up will not be used
for local error handling. Local error handling is <i>only</i>
interested in the error code, not the paths or string message.<br>
</div>
</blockquote>
That very much depends on the type of application and the call
context. Generalizations like that are rarely useful.<br>
<blockquote
cite=3D"mid:19179fc2-61c5-4cb1-bb0a-169b0d033a8d@isocpp.org"
type=3D"cite">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div><br>
This improves on the original only in that you don't have
to throw the exception in order to introspect it. But you
are still creating needless overhead for local error
handling users. It's biased towards those using
exceptions.<br>
</div>
</blockquote>
Allocation has to happen in both cases for user defined types.
expected<> has an advantage here because it isn't
dragged down by the throw machinery. The "needless" overhead
is pretty much mandatory.<br>
</div>
</blockquote>
<div><br>
This has already been discussed, and no it is not mandatory. Not
if you want to handle the error locally. The path object(s) in
the `filesystem_error` are data that the local context <i>already
has</i>. So it doesn't need them delivered back to them. It
only makes sense to provide that data if you're doing non-local
error handling.<br>
</div>
</blockquote>
Depending on whether E=3Dexception_ptr in which case an allocation is
still required, but one is still better off than actually throwing.
As to motivation why one would want to capture the exception instead
of just propagating it see Alexandrescu's talks.<br>
<blockquote
cite=3D"mid:19179fc2-61c5-4cb1-bb0a-169b0d033a8d@isocpp.org"
type=3D"cite">
<div><br>
This is why FileSystem doesn't have an interface that fills in a
`filesystem_error` by reference. It takes `error_code` by
reference, because that's the minimum information that the local
context needs.<br>
<br>
Locally, all you want is an error_code. Only for non-local
handling do you want a full `filesystem_error`.<br>
</div>
</blockquote>
What people actually "want" is, if ever, only known after the fact
and hard to theorize around beforehand. Again, generalizations don't
help. As doesn't imposing your own experience on everybody else.<br>
<blockquote
cite=3D"mid:19179fc2-61c5-4cb1-bb0a-169b0d033a8d@isocpp.org"
type=3D"cite">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div><br>
Oh, and I believe you said this on another thread:<br>
<br>
> If E means Error, we can not throw another error
while copying it.<br>
<br>
If we are to follow that requirement, then you <i>cannot
</i>embed `path` objects in the return value either, for
the same reason you can't use `std::string`. Both of them
have throwing copy operations (but they are no-throw
moveable). So filesystem_error couldn't be used.<br>
</div>
</blockquote>
Of course you can. Proven by the simple fact people already
use and throw filesystem_error. As long as the copy doesn't
*actually* fail everything's fine. *If* the copy fails do as a
throw would and simply terminate since the two mechanisms are
analogous.<br>
</div>
</blockquote>
<div><br>
I said "if we are to follow that requirement;" that should not
be taken as an <i>endorsement</i> of said requirement.
Obviously `filesystem_error` is a perfectly functional exception
type. My point was that he was talking elsewhere about adding
requirements to `expected` that he hadn't realized would <i>forbid<=
/i>
the use of `expected<T, filesystem_error>`.)<br>
</div>
</blockquote>
Well, since you quoted him out of context, I'm going to reply out of
context as I'm not going to search for the discussion that quote
came from.<br>
"If E means Error, we can not throw another error while copying it."<br=
>
This behavior matches the requirements imposed on exception types
for throw expressions. They don't need to be noexcept, they just
aren't allowed to actually throw when copied. If expected follows
that pattern and terminates if an exception is thrown during copy
construction or assignment it doesn't have stricter requirements
than throw currently does.<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------050401050707060609020108--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 14 Nov 2015 19:32:29 +0100
Raw View
Le 14/11/2015 15:49, Nicol Bolas a =C3=A9crit :
> On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
>>> OK, here is where I feel we are in the conversation.
>>>
>>> People seem to want `value` to throw different, customization
>> exceptions.
>>> And as far as I can tell, the main (or only) reason to do so is to allo=
w
>>> people to write a single API function, which uses exceptions based on
>> how
>>> the return value is used. This would achieving the effect of FileSystem
>>> TS's design, but without multiple overloads.
>>>
>>> I've demonstrated that a straightforward implementation of this is not
>>> viable. It will result in either local try/catch blocks just to handle
>>> simple error codes and lots of redundant data, or non-local functions
>> will
>>> not have enough information to fully resolve the error. There does not
>> seem
>>> to be a middle way; one side or the other always seems to lose.
>> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not a
>> good candidate to manage local recovery.
>> expected<T,filesystem_error> should be a better candidate.
>>
> You will recall that one of my arguments was about bloat.
> `filesystem_error` contains up to two `path` objects, which given small
> string optimization and its error_code make the resulting
> `filesystem_error` object take up *at least* 40 bytes (16 per `path`, + 8
> for the error code). That doesn't even count the vtable pointer (since it=
's
> derived from `std::exception`.
This is a feature (problem) of the FileSystem TS, not of expected.
>
> That's not to mention the overhead of passing back a path that the local
> context already has. Which may mean allocating memory, depending on the
> path's length.
This is a feature (problem) of the FileSystem TS, not of expected.
>
> This improves on the original only in that you don't have to throw the
> exception in order to introspect it. But you are still creating needless
> overhead for local error handling users. It's biased towards those using
> exceptions.
>
> Oh, and I believe you said this on another thread:
>
>> If E means Error, we can not throw another error while copying it.
> If we are to follow that requirement, then you *cannot *embed `path`
> objects in the return value either, for the same reason you can't use
> `std::string`. Both of them have throwing copy operations (but they are
> no-throw moveable). So filesystem_error couldn't be used.
If filesystem_error copy throws terminate will be called. We could do=20
the same in expected.
>
> This requirement would also mean that you couldn't put a lot of flavorful
> error types into the object. That's fine for simple error codes and the
> like. But not for the kinds of objects that are appropriate for exception=
s.
>
> So by your own design ideas, what you suggested is forbidden.
This is not specific to expected but to error reporting. The same=20
applies to any exception.
>
> I suggest to start a specific thread for how expected can improve
>> FileSystem TS interface (if any), independently of whether there are two
>> overload or only one.
>>
> FileSystem is relevant to this thread because APIs like it are the primar=
y
> motivation for wanting expected to have customized exceptions on `value`.
Do you mean that we need to find a consensual solution for filesystem in=20
this thread?
>
> Every reason people want this customization ultimately boils down to "I
> want a function to support local and non-local errors with only one
> overload." That's why the FileSystem TS interface is important; it's a
> perfect use case to prove that your customization design is functional. I=
f
> a particular customization design can't solve the FileSystem TS issue
> adequately, then it's clear that this particular customization design isn=
't
> going to actually solve the problem at all.
>
> So the best way to judge any suggested customization mechanism is to judg=
e
> it by whether it solves the problem that people want it to solve. And
> FileSystem is an excellent example of that problem.
I see the things from a different perspective. I don't know what the=20
user can do with expected, and so I find that giving she a degree of=20
freedom is the good design for a library. It seems that this argument is=20
not shared.
Lets suppose for a moment that we don't customize. Is there something=20
that value() can throw and that is a good compromise?
My opinion is that we will not find this consensus.
We can also not provide value at all.
>
>>> Vicente put forth a sketch of an idea for unifying such APIs. But the
>> idea
>>> lacked any real details, so it's not clear if it would actually resolve
>> the
>>> problem.
>> Right, it is an idea as said.
>>> If it is not possible to develop such a way, to have a single function
>>> provide both local and non-local exceptions without overloading, then I
>>> submit that there is no reason to give `value` customized exceptions.
>> Since
>>> that seemed to be the primary motivation, if it's not possible, then it
>>> seems to me that there is no motivation for this feature.
>> I give other useful customization cases.
>>
> No, you stated the behavior you wanted to customize. You didn't say why y=
ou
> wanted to do it. That would be the motivation part.
Do you need to justify why a function could throw different exceptions=20
and not only one?
>
>>> It seems to me that there are two outstanding questions:
>>>
>>> 1) Is there an effective means to have one function, based on
>> `expected`,
>>> which services the needs of local and non-local error handling just as
>> well
>>> as having two overloads? Is there a fleshed-out design for such an
>>> interface?
>> It depends if people want to find a solution or not. IMHO, nobody has
>> spent enough time to presented a proposal on how to use expected for
>> FileSystem TS.
>>> 2) What do you need to be able to do that requires `value` to throw
>>> customized exceptions? And again, don't just say "I want `expected<T,
>>> variant<E1, E2,...>>` to throw the particular error in the variant." Yo=
u
>>> need to explain *why* you need `value` to do that. Explain what you are
>>> trying to do that makes this behavior important.
>>>
>> I want expected<T, variant<E1, ...>> to throw the particular error in
>> the variant :)
>> Why? Because a function can have several kind of errors.
>> E.g. expected<T, variant<error_code, filesystem_error>>
>>
>>
>> Some time ago I suggested a variadic version of expected
>> expected<T, error_code, filesystem_error>
>
>> This gives you local and non-local error reporting tool.
>
> This is better for local error handling, since you're not passing back da=
ta
> that the local context already has. But it still causes bloat to the size
> of `expected`.
Would this be a problem?
>
> It also makes such a multi-variant becomes a *lot* more difficult to work
> with. I'm pretty sure you'd lose your precious `await` propagation, since
> `await` has no way of knowing which error to fetch, which has to be a
> *compile-time* selection of a *runtime-defined* value. Even visitation
> wouldn't work, since you can't return different types.
I don't see any problem with await. The monad would be expected<_, E1,=20
...., En>
await transfer the error which would be variant<E1, ..., En>.
>
> This design also forces people to use an awkward `std::get`-style interfa=
ce
> to get the particular error out, as opposed to the much simpler `.error`.
You have visitation also. And I hope we will have pattern matching not=20
too far.
>
> This is what we would call "scope creep". It comes from having a poor
> vision of the overall design for the type, from trying to make a type tha=
t
> solves *everyone's* problems. It tends to end up with a type that solves
> everyone's problems, but does so very sub-optimally.
I don't see the situation like you. expected<T,E> is married with=20
functional programming, so we need to make use of those tools.
>
> My vision of `expected` is this: it's for local/non-throwing error
> handling. To that end, it should be as simple to use as possible, with a
> clear and obvious API and minimal overhead.
>
> Multiple error types are not useful for local handling; having multiple
> error types is useful only for two cases. 1) Single-function local and
> non-local error handling, as in your case above. And 2) the ability to
> propagate errors out of a function from multiple `expected` sources. Well=
,
> if `expected` is for local handling, its ability to propagate errors is
> irrelevant (you don't propagate errors if you're handling them locally). =
So
> too is its ability to allow single-function non-local error handling.
>
> I would much rather have `expected<T, E>`, which is simple and easy to us=
e.
> If you want to use `expected` outside of local error handling, then its
> interface will become increasingly more complicated. Keep the main class
> simple to use. So people who want to use the type against its purpose
> should have to do `expected<T, variant<E1, E2, ...>>` explicitly. Yes,
> that's a lot harder to use, but you would only use it when you're using
> `expected` for something that `expected` isn't really meant to do.
You know exactly what you want, it seems simple and everybody would=20
agree with. I propose you to write a proposal for the expected you think=20
the committee wants. The expected I WANT is not as simple as yours.
Note that we had up to 4 proposals for variant in the last ML, and we=20
have 2 for coroutines.
> That you could
>> prefer two overloaded function is another matter.
>>
>> Vicente
>>
>> P.S. Don't forget we a constructing an expected proposal, that respond
>> to the user needs (and the standard library can be a user).
>>
>> P.S.S. expected proposal has a visitation interface
>>
> A visitation interface would only be reasonable for `expected` if it
> allowed multiple error types natively. Otherwise, nobody would use it. An=
d
> even then, you would only visit it for the errors within it.
Why? I can visit the value or the error?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 14 Nov 2015 19:40:42 +0100
Raw View
Le 14/11/2015 18:38, Nicol Bolas a =C3=A9crit :
> On Saturday, November 14, 2015 at 11:21:09 AM UTC-5, Miro Knejp wrote:
>> Am 14.11.2015 um 15:49 schrieb Nicol Bolas:
>>
>> On Saturday, November 14, 2015 at 3:54:08 AM UTC-5, Vicente J. Botet
>> Escriba wrote:
>>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
>>>> OK, here is where I feel we are in the conversation.
>>>>
>>>> People seem to want `value` to throw different, customization
>>> exceptions.
>>>> And as far as I can tell, the main (or only) reason to do so is to
>>> allow
>>>> people to write a single API function, which uses exceptions based on
>>> how
>>>> the return value is used. This would achieving the effect of FileSyste=
m
>>>> TS's design, but without multiple overloads.
>>>>
>>>> I've demonstrated that a straightforward implementation of this is not
>>>> viable. It will result in either local try/catch blocks just to handle
>>>> simple error codes and lots of redundant data, or non-local functions
>>> will
>>>> not have enough information to fully resolve the error. There does not
>>> seem
>>>> to be a middle way; one side or the other always seems to lose.
>>> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not a
>>> good candidate to manage local recovery.
>>> expected<T,filesystem_error> should be a better candidate.
>>>
>> You will recall that one of my arguments was about bloat.
>> `filesystem_error` contains up to two `path` objects, which given small
>> string optimization and its error_code make the resulting
>> `filesystem_error` object take up *at least* 40 bytes (16 per `path`, + =
8
>> for the error code). That doesn't even count the vtable pointer (since i=
t's
>> derived from `std::exception`.
>>
>> That's not to mention the overhead of passing back a path that the local
>> context already has. Which may mean allocating memory, depending on the
>> path's length.
>>
>> Does the size of the exception object really matter in practice? I belie=
ve
>> we can all agree that *if* an exception is thrown any performance
>> considerations are out the window. The size of the exception object only
>> really matters in bad_alloc situations which the standard library has to
>> worry about.
>>
> Yeah, kinda. Not just the size of the expected (people can be very picky
> about stack space. See discussions about `variant` double-buffering for a=
n
> example), but also the allocation of memory.
>
> Remember: many users of `expected` operate in contexts where exceptions
> simply aren't allowed. And most of those contexts *also* forbid random
> memory allocations. So they would be unable to use `expected` with error
> objects that allocate memory. Especially if there were no way to provide =
an
> allocator or some other allocation control.
>
> And let's not forget that the space taken up will not be used for local
> error handling. Local error handling is *only* interested in the error
> code, not the paths or string message.
Are you saying that the the adaptation of FileSystem TS to expected=20
couldn't return an filesystem_error?
>> This improves on the original only in that you don't have to throw the
>> exception in order to introspect it. But you are still creating needless
>> overhead for local error handling users. It's biased towards those using
>> exceptions.
>>
>> Allocation has to happen in both cases for user defined types. expected<=
>
>> has an advantage here because it isn't dragged down by the throw machine=
ry.
>> The "needless" overhead is pretty much mandatory.
>>
> This has already been discussed, and no it is not mandatory. Not if you
> want to handle the error locally. The path object(s) in the
> `filesystem_error` are data that the local context *already has*. So it
> doesn't need them delivered back to them. It only makes sense to provide
> that data if you're doing non-local error handling.
>
> This is why FileSystem doesn't have an interface that fills in a
> `filesystem_error` by reference. It takes `error_code` by reference,
> because that's the minimum information that the local context needs.
>
> Locally, all you want is an error_code. Only for non-local handling do yo=
u
> want a full `filesystem_error`.
So how would you adapt the FileSystem TS to use expected?
> =20
>
>> Oh, and I believe you said this on another thread:
>>
>>> If E means Error, we can not throw another error while copying it.
>> If we are to follow that requirement, then you *cannot *embed `path`
>> objects in the return value either, for the same reason you can't use
>> `std::string`. Both of them have throwing copy operations (but they are
>> no-throw moveable). So filesystem_error couldn't be used.
>>
>> Of course you can. Proven by the simple fact people already use and thro=
w
>> filesystem_error. As long as the copy doesn't *actually* fail everything=
's
>> fine. *If* the copy fails do as a throw would and simply terminate since
>> the two mechanisms are analogous.
>>
> I said "if we are to follow that requirement;" that should not be taken a=
s
> an *endorsement* of said requirement. Obviously `filesystem_error` is a
> perfectly functional exception type. My point was that he was talking
> elsewhere about adding requirements to `expected` that he hadn't realized
> would *forbid* the use of `expected<T, filesystem_error>`.
>
Who is he?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 15:10:40 -0800 (PST)
Raw View
------=_Part_686_43888317.1447542640282
Content-Type: multipart/alternative;
boundary="----=_Part_687_1888716062.1447542640283"
------=_Part_687_1888716062.1447542640283
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 12:41:24 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 14/11/2015 16:37, Nicol Bolas a =C3=A9crit :=20
> > On Saturday, November 14, 2015 at 4:33:48 AM UTC-5, Vicente J. Botet=20
> > Escriba wrote:=20
> >> Le 14/11/2015 09:54, Vicente J. Botet Escriba a =C3=A9crit :=20
> >>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :=20
> >>>> OK, here is where I feel we are in the conversation.=20
> >>>>=20
> >>>> People seem to want `value` to throw different, customization=20
> >>>> exceptions.=20
> >>>> And as far as I can tell, the main (or only) reason to do so is to=
=20
> >> allow=20
> >>>> people to write a single API function, which uses exceptions based o=
n=20
> >>>> how=20
> >>>> the return value is used. This would achieving the effect of=20
> FileSystem=20
> >>>> TS's design, but without multiple overloads.=20
> >>>>=20
> >>>> I've demonstrated that a straightforward implementation of this is=
=20
> not=20
> >>>> viable. It will result in either local try/catch blocks just to=20
> handle=20
> >>>> simple error codes and lots of redundant data, or non-local function=
s=20
> >>>> will=20
> >>>> not have enough information to fully resolve the error. There does=
=20
> >>>> not seem=20
> >>>> to be a middle way; one side or the other always seems to lose.=20
> >>> Hmm, I believe you demonstrated that expected<T,exception_ptr> is not=
=20
> >>> a good candidate to manage local recovery.=20
> >>> expected<T,filesystem_error> should be a better candidate.=20
> >>>=20
> >>> I suggest to start a specific thread for how expected can improve=20
> >>> FileSystem TS interface (if any), independently of whether there are=
=20
> >>> two overload or only one.=20
> >>>> Vicente put forth a sketch of an idea for unifying such APIs. But th=
e=20
> >>>> idea=20
> >>>> lacked any real details, so it's not clear if it would actually=20
> >>>> resolve the=20
> >>>> problem.=20
> >>> Right, it is an idea as said.=20
> >> template <class EC>=20
> >> requires Same<EC, error_code> or Same<EC,=20
> filesystem::filesystem_error>=20
> >> expected<X, EC> filesystem::function(...);=20
> >>=20
> >> auto x =3D filesystem::function<error_code>(...);=20
> >> or=20
> >> auto x =3D filesystem::function<filesystem::filesystem_error>(..=
..);=20
> >>=20
> >> The filesystem function know at compile time which kind of error must=
=20
> be=20
> >> reported and could at compile time build it without any performance=20
> >> penalty.=20
> >>=20
> > OK, that's a design. It provides zero overhead for local handlers.=20
> Though=20
> > it does cause some overhead for non-local handlers; the=20
> `filesystem_error`=20
> > has to be constructed, then copied into the actual exception.=20
> It can be constructed in place.
>
You're talking about the error in the expected. I'm talking about the=20
exception that `value` throws. At some point, value will do `throw=20
this->error()`. Well, that has to copy the object into the exception=20
pointer.
=20
> >>=20
> >> Sorry, this should not work for FileSystem, as the user need to state=
=20
> >> which kind of error she wants.=20
> >>=20
> >> Anyway, you see what I mean. If now a function can throw exceptions E1=
,=20
> >> ..., En, transforming it to expected would result in expected<T,=20
> >> variant<E1, ..., En>> and the less surprising exception to throw when=
=20
> >> value is called is IMO Ei.=20
> >>=20
> > If you have an API that throws, merely sticking those exceptions in an=
=20
> > `expected`, even as the actual exception types themselves (rather than=
=20
> > `exception_ptr`), causes bloat for local error handling.=20
> We surely are not talking of the same thing. IMO it is the opposite, it=
=20
> helps to manage local errors.=20
> The case for having a variant could be to have specific filesystem_error=
=20
> classes each one with the data needed. It is not to make the difference=
=20
> between local and non-local error handling. For example instead of just=
=20
> one exception class you could have 3. No path, 1 path 2 paths.
>
How does that cut down on bloat? A filesystem_error object that wasn't give=
=20
paths won't allocate memory for them. But it still has to statically have=
=20
empty path objects. Putting them in a variant won't change that, because=20
the total size of the variant will be defined by the biggest component=20
type. So a `variant<filesystem_error, filesystem_error_path,=20
filesystem_error_path_path>` will still be just as large.
Not to mention, retrieving the useful information creates lots of syntactic=
=20
burden at the receiving site:
auto e =3D fs::file_size(p);
if(!e)
{
error_code ec =3D visit(fetch_error_code(), e);
switch(ec.value())
{
//Use error code.
}
}
Remember: from the local handler perspective, the *only useful information*=
=20
that `filesystem_error` provides is the error code. Everything else is=20
information which is locally available to the handler.
> That's why your=20
> > FileSystem design above returns *different* error types based on the=20
> user=20
> > desiring local or non-local handling.=20
> Do you think that all the APIs need to select between local and=20
> non-local handling?=20
>
No. I specifically brought up functions like stol and so forth as examples=
=20
where `expected` was the only interface needed. Similarly, I wouldn't=20
expect `future<T>` to provide a version of `.get` that returns a=20
`expected<T, exception_ptr>`.
I don't master the FileSystem TS. IIUC the exception throw has an=20
> error_code and possibly two paths that should appear in the call, isn't=
=20
> it? If this is correct, what would be the advantage to returning=20
> expected<T, filesystem_error> over expected<T, error_code>?=20
> With expected<T,error_code> the user can add anything she considers=20
> useful while propagating the error.=20
>
> If we had=20
>
> expected<T,error_code> fs::file_size(const path&);=20
>
> the user could transform the local handling into a non-local handling=20
> adding the path as follows=20
>
> auto x =3D fs::file_size(p).catch_error(wrap_with_path(p)).value();=
=20
>
Allow me to restate the point you seem to keep missing here:
*If you attempt to have a single function provide both local and non-local=
=20
error handling, you will bias that API towards either local or non-local=20
handling.*
Your suggestion is biased it towards local handling, forcing users who want=
=20
exceptions to add a bunch of syntax to get decent exceptions. I see no=20
reason to make people who want exceptions have to go through that much BS.
If you're going to allow the caller to choose between local and non-local=
=20
error handling, said caller shouldn't make that choice based on how much=20
text they have to write. Your way would make people use expected directly=
=20
because doing otherwise is just too painful to bother with.
I would much rather have multiple overloads than have to type that nonsense=
..
=20
>
> when wrap_with_path will construct an error that contains the error code=
=20
> and the path.=20
>
> This design will need only one overload, which will simplify the TS=20
> implementation.
And you just proved that any "TS implementation" simplification is *minimal=
*.=20
Because they could simply add an exception-based overload that looks=20
exactly like your code.
So why should such a TS *not* have the overload, when it's so trivial to=20
implement and maintain, yet would be a massive eyesore for the user?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_687_1888716062.1447542640283
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 12:41:24 PM UTC-5, Vicente J. Botet Escri=
ba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 14/11/2015 16:37, =
Nicol Bolas a =C3=A9crit :
<br>> On Saturday, November 14, 2015 at 4:33:48 AM UTC-5, Vicente J. Bot=
et
<br>> Escriba wrote:
<br>>> Le 14/11/2015 09:54, Vicente J. Botet Escriba a =C3=A9crit :
<br>>>> Le 14/11/2015 01:38, Nicol Bolas a =C3=A9crit :
<br>>>>> OK, here is where I feel we are in the conversation.
<br>>>>>
<br>>>>> People seem to want `value` to throw different, custom=
ization
<br>>>>> exceptions.
<br>>>>> And as far as I can tell, the main (or only) reason to=
do so is to
<br>>> allow
<br>>>>> people to write a single API function, which uses exce=
ptions based on
<br>>>>> how
<br>>>>> the return value is used. This would achieving the eff=
ect of FileSystem
<br>>>>> TS's design, but without multiple overloads.
<br>>>>>
<br>>>>> I've demonstrated that a straightforward implement=
ation of this is not
<br>>>>> viable. It will result in either local try/catch block=
s just to handle
<br>>>>> simple error codes and lots of redundant data, or non-=
local functions
<br>>>>> will
<br>>>>> not have enough information to fully resolve the error=
.. There does
<br>>>>> not seem
<br>>>>> to be a middle way; one side or the other always seems=
to lose.
<br>>>> Hmm, I believe you demonstrated that expected<T,excepti=
on_ptr> is not
<br>>>> a good candidate to manage local recovery.
<br>>>> expected<T,filesystem_error> should be a better cand=
idate.
<br>>>>
<br>>>> I suggest to start a specific thread for how expected can =
improve
<br>>>> FileSystem TS interface (if any), independently of whether=
there are
<br>>>> two overload or only one.
<br>>>>> Vicente put forth a sketch of an idea for unifying suc=
h APIs. But the
<br>>>>> idea
<br>>>>> lacked any real details, so it's not clear if it w=
ould actually
<br>>>>> resolve the
<br>>>>> problem.
<br>>>> Right, it is an idea as said.
<br>>> template <class EC>
<br>>> requires Same<EC, error_code> or =C2=A0Same<EC, files=
ystem::filesystem_error>
<br>>> expected<X, EC> filesystem::function(...);
<br>>>
<br>>> =C2=A0 =C2=A0 =C2=A0 auto x =3D filesystem::function<error_=
<wbr>code>(...);
<br>>> or
<br>>> =C2=A0 =C2=A0 =C2=A0 auto x =3D filesystem::function<<wbr>f=
ilesystem::filesystem_error>(<wbr>...);
<br>>>
<br>>> The filesystem function know at compile time which kind of err=
or must be
<br>>> reported and could at compile time build it without any perfor=
mance
<br>>> penalty.
<br>>>
<br>> OK, that's a design. It provides zero overhead for local handl=
ers. Though
<br>> it does cause some overhead for non-local handlers; the `filesyste=
m_error`
<br>> has to be constructed, then copied into the actual exception.
<br>It can be constructed in place.<br></blockquote><div><br>You're tal=
king about the error in the expected. I'm talking about the exception t=
hat `value` throws. At some point, value will do `throw this->error()`. =
Well, that has to copy the object into the exception pointer.<br>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">>>
<br>>> Sorry, this should not work for FileSystem, as the user need t=
o state
<br>>> which kind of error she wants.
<br>>>
<br>>> Anyway, you see what I mean. If now a function can throw excep=
tions E1,
<br>>> ..., En, transforming it to expected would result in expected&=
lt;T,
<br>>> variant<E1, ..., En>> and the less surprising excepti=
on to throw when
<br>>> value is called is IMO Ei.
<br>>>
<br>> If you have an API that throws, merely sticking those exceptions i=
n an
<br>> `expected`, even as the actual exception types themselves (rather =
than
<br>> `exception_ptr`), causes bloat for local error handling.
<br>We surely are not talking of the same thing. IMO it is the opposite, it=
=20
<br>helps to manage local errors.
<br>The case for having a variant could be to have specific filesystem_erro=
r=20
<br>classes each one with the data needed. It is not to make the difference=
=20
<br>between local and non-local error handling. For example instead of just=
=20
<br>one exception class you could have 3. No path, 1 path 2 paths.<br></blo=
ckquote><div><br>How does that cut down on bloat? A filesystem_error object=
that wasn't give paths won't allocate memory for them. But it stil=
l has to statically have empty path objects. Putting them in a variant won&=
#39;t change that, because the total size of the variant will be defined by=
the biggest component type. So a `variant<filesystem_error, filesystem_=
error_path, filesystem_error_path_path>` will still be just as large.<br=
><br>Not to mention, retrieving the useful information creates lots of synt=
actic burden at the receiving site:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> e </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> fs</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">file=
_size</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">p</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">e</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 error_code ec </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> visit</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">fetch_error_=
code</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> e</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">switch</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">ec</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//Use error code.</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span></div></code></div><br>Remember: from the local handler perspective,=
the <i>only useful information</i> that `filesystem_error` provides is the=
error code. Everything else is information which is locally available to t=
he handler.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> =
That's why your
<br>> FileSystem design above returns *different* error types based on t=
he user
<br>> desiring local or non-local handling.
<br>Do you think that all the APIs need to select between local and=20
<br>non-local handling?
<br></blockquote><div><br>No. I specifically brought up functions like stol=
and so forth as examples where `expected` was the only interface needed. S=
imilarly, I wouldn't expect `future<T>` to provide a version of `=
..get` that returns a `expected<T, exception_ptr>`.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">I don't master the FileSystem T=
S. IIUC the exception throw has an=20
<br>error_code and possibly two paths that should appear in the call, isn&#=
39;t=20
<br>it? =C2=A0If this is correct, what would be the advantage to returning=
=20
<br>expected<T, filesystem_error> over expected<T, error_code>?
<br>With expected<T,error_code> the user can add anything she conside=
rs=20
<br>useful while propagating the error.
<br>
<br>If we had
<br>
<br>=C2=A0 =C2=A0 =C2=A0expected<T,error_code> fs::file_size(const pa=
th&);
<br>
<br>the user could transform the local handling into a non-local handling=
=20
<br>adding the path as follows
<br>
<br>=C2=A0 =C2=A0 =C2=A0auto x =3D fs::file_size(p).catch_error(<wbr>wrap_w=
ith_path(p)).value();
<br></blockquote><div><br>Allow me to restate the point you seem to keep mi=
ssing here:<br><br><u><b>If you attempt to have a single function provide b=
oth local and non-local error handling, you will bias that API towards eith=
er local or non-local handling.</b></u><br><br>Your suggestion is biased it=
towards local handling, forcing users who want exceptions to add a bunch o=
f syntax to get decent exceptions. I see no reason to make people who want =
exceptions have to go through that much BS.<br><br>If you're going to a=
llow the caller to choose between local and non-local error handling, said =
caller shouldn't make that choice based on how much text they have to w=
rite. Your way would make people use expected directly because doing otherw=
ise is just too painful to bother with.<br><br>I would much rather have mul=
tiple overloads than have to type that nonsense.<br>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
<br>when wrap_with_path will construct an error that contains the error cod=
e=20
<br>and the path.
<br>
<br>This design will need only one overload, which will simplify the TS=20
<br>implementation.</blockquote><div><br>And you just proved that any "=
;TS implementation" simplification is <i>minimal</i>. Because they cou=
ld simply add an exception-based overload that looks exactly like your code=
..<br><br>So why should such a TS <i>not</i> have the overload, when it'=
s so trivial to implement and maintain, yet would be=C2=A0 a massive eyesor=
e for the user?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_687_1888716062.1447542640283--
------=_Part_686_43888317.1447542640282--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 15:29:51 -0800 (PST)
Raw View
------=_Part_394_829292356.1447543791261
Content-Type: multipart/alternative;
boundary="----=_Part_395_938478604.1447543791262"
------=_Part_395_938478604.1447543791262
Content-Type: text/plain; charset=UTF-8
On Saturday, November 14, 2015 at 1:13:58 PM UTC-5, Miro Knejp wrote:
>
> Am 14.11.2015 um 18:38 schrieb Nicol Bolas:
>
> On Saturday, November 14, 2015 at 11:21:09 AM UTC-5, Miro Knejp wrote:
>>
>> Does the size of the exception object really matter in practice? I
>> believe we can all agree that *if* an exception is thrown any performance
>> considerations are out the window. The size of the exception object only
>> really matters in bad_alloc situations which the standard library has to
>> worry about.
>>
>
> Yeah, kinda. Not just the size of the expected (people can be very picky
> about stack space. See discussions about `variant` double-buffering for an
> example), but also the allocation of memory.
>
> Remember: many users of `expected` operate in contexts where exceptions
> simply aren't allowed.
>
> I'm sure you have numbers to back up this claim, as always. The original
> motivation of expected as introduced by Alexandrescu was based around
> expection_ptr so saying that *many* (what % is that?) don't allow
> exceptions is pretty much useless without data.
>
We have an *entire study group* that has, as one of its founding purposes
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4526.pdf>, the
desire to make C++ as independent of exceptions as possible. And if that's
going to happen, they need some form of alternate error reporting mechanism.
So I think they would have a very great interest in having a form of error
handling that doesn't involve throwing and catching exceptions. One which
is built around low latency and low overhead, with predictable performance
metrics. One that many standard library APIs could freely use as an
alternative to exceptions.
> This is why FileSystem doesn't have an interface that fills in a
> `filesystem_error` by reference. It takes `error_code` by reference,
> because that's the minimum information that the local context needs.
>
> Locally, all you want is an error_code. Only for non-local handling do you
> want a full `filesystem_error`.
>
> What people actually "want" is, if ever, only known after the fact and
> hard to theorize around beforehand.
>
So in your view, we should just assume that everyone would be totally fine
with integer return values taking up 40 bytes and simple error codes
allocating memory until we get lots and lots of people complaining about
it, then do something to resolve it? After it's been in the API and
millions of people are writing code against it?
That's a path that leads to iostreams.
I really hate bringing this up, because I'm kinda using a principle as a
club. But I seem to recall there being something in C++ about not paying
for what you don't use.
> Again, generalizations don't help. As doesn't imposing your own experience
> on everybody else.
>
Nothing I said was a "generalization". It's a *fact*, based on the fact
that the user was the one who passed the parameter in. Therefore, at some
point, the user *must* have had access to it. And thus, they could retain
it if they wanted to.
If you believe my statement to be false, prove it. Show me some example
code where it is impossible for the local context to know the path. Note
that I said "impossible", not merely "he could have but didn't bother."
Oh, and just in case you want to quibble about things, "local context"
means "the immediate caller of the function".
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_395_938478604.1447543791262
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 1:13:58 PM UTC-5, Miro Knejp wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
Am 14.11.2015 um 18:38 schrieb Nicol Bolas:<br>
<blockquote type=3D"cite">On Saturday, November 14, 2015 at 11:21:09 AM=
UTC-5,
Miro Knejp wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> Does the size of the exc=
eption object really matter in
practice? I believe we can all agree that *if* an exception is
thrown any performance considerations are out the window. The
size of the exception object only really matters in bad_alloc
situations which the standard library has to worry about.<br>
</div>
</blockquote>
<div><br>
Yeah, kinda. Not just the size of the expected (people can be
very picky about stack space. See discussions about `variant`
double-buffering for an example), but also the allocation of
memory.<br>
<br>
Remember: many users of `expected` operate in contexts where
exceptions simply aren't allowed. </div>
</blockquote>
I'm sure you have numbers to back up this claim, as always. The
original motivation of expected as introduced by Alexandrescu was
based around expection_ptr so saying that *many* (what % is that?)
don't allow exceptions is pretty much useless without data.<br></di=
v></blockquote><div><br>We have an <i>entire study group</i> that has, as <=
a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4526.pdf=
">one of its founding purposes</a>, the desire to make C++ as independent o=
f exceptions as possible. And if that's going to happen, they need some=
form of alternate error reporting mechanism.<br><br>So I think they would =
have a very great interest in having a form of error handling that doesn=
9;t involve throwing and catching exceptions. One which is built around low=
latency and low overhead, with predictable performance metrics. One that m=
any standard library APIs could freely use as an alternative to exceptions.=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFF=
FFF" text=3D"#000000">
<blockquote type=3D"cite">
<div>
This is why FileSystem doesn't have an interface that fills in =
a
`filesystem_error` by reference. It takes `error_code` by
reference, because that's the minimum information that the loca=
l
context needs.<br>
<br>
Locally, all you want is an error_code. Only for non-local
handling do you want a full `filesystem_error`.<br>
</div>
</blockquote>
What people actually "want" is, if ever, only known after the=
fact
and hard to theorize around beforehand.</div></blockquote><div><br>So i=
n your view, we should just assume that everyone would be totally fine with=
integer return values taking up 40 bytes and simple error codes allocating=
memory until we get lots and lots of people complaining about it, then do =
something to resolve it? After it's been in the API and millions of peo=
ple are writing code against it?<br><br>That's a path that leads to ios=
treams.<br><br>I really hate bringing this up, because I'm kinda using =
a principle as a club. But I seem to recall there being something in C++ ab=
out not paying for what you don't use.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">Again=
, generalizations don't
help. As doesn't imposing your own experience on everybody else.<br=
></div></blockquote><div><br>Nothing I said was a "generalization"=
;. It's a <i>fact</i>, based on the fact that the user was the one who =
passed the parameter in. Therefore, at some point, the user <i>must</i> hav=
e had access to it. And thus, they could retain it if they wanted to.<br><b=
r>If you believe my statement to be false, prove it. Show me some example c=
ode where it is impossible for the local context to know the path. Note tha=
t I said "impossible", not merely "he could have but didn=
9;t bother."<br><br>Oh, and just in case you want to quibble about thi=
ngs, "local context" means "the immediate caller of the func=
tion".</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_395_938478604.1447543791262--
------=_Part_394_829292356.1447543791261--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 15:37:23 -0800 (PST)
Raw View
------=_Part_477_1000667835.1447544243097
Content-Type: multipart/alternative;
boundary="----=_Part_478_1720227832.1447544243097"
------=_Part_478_1720227832.1447544243097
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 1:40:46 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 14/11/2015 18:38, Nicol Bolas a =C3=A9crit :=20
> > Yeah, kinda. Not just the size of the expected (people can be very pick=
y=20
> > about stack space. See discussions about `variant` double-buffering for=
=20
> an=20
> > example), but also the allocation of memory.=20
> >=20
> > Remember: many users of `expected` operate in contexts where exceptions=
=20
> > simply aren't allowed. And most of those contexts *also* forbid random=
=20
> > memory allocations. So they would be unable to use `expected` with erro=
r=20
> > objects that allocate memory. Especially if there were no way to provid=
e=20
> an=20
> > allocator or some other allocation control.=20
> >=20
> > And let's not forget that the space taken up will not be used for local=
=20
> > error handling. Local error handling is *only* interested in the error=
=20
> > code, not the paths or string message.=20
> Are you saying that the the adaptation of FileSystem TS to expected=20
> couldn't return an filesystem_error?
>
Could it? Yes, it could. There is nothing in `expected` that would prevent=
=20
it.
My point is that it *shouldn't*. For the reasons I have explained at length=
..
=20
> > This has already been discussed, and no it is not mandatory. Not if you=
=20
> > want to handle the error locally. The path object(s) in the=20
> > `filesystem_error` are data that the local context *already has*. So it=
=20
> > doesn't need them delivered back to them. It only makes sense to provid=
e=20
> > that data if you're doing non-local error handling.=20
> >=20
> > This is why FileSystem doesn't have an interface that fills in a=20
> > `filesystem_error` by reference. It takes `error_code` by reference,=20
> > because that's the minimum information that the local context needs.=20
> >=20
> > Locally, all you want is an error_code. Only for non-local handling do=
=20
> you=20
> > want a full `filesystem_error`.=20
> So how would you adapt the FileSystem TS to use expected?
>
Take every function that uses `error_code &ec`. Have it return an=20
`expected<T, error_code>` instead.
Problem solved.
This gives those who want local error handling the minimum information they=
=20
need with as little bloat as possible. The syntax is much nicer for them,=
=20
compared to having to use an output parameter.
Those who want non-local error handling are not affected in the slightest.=
=20
They call functions exactly as before. And users are easily able to switch=
=20
between them based on their needs.
=20
> > =20
> >=20
> >> Oh, and I believe you said this on another thread:=20
> >>=20
> >>> If E means Error, we can not throw another error while copying it.=20
> >> If we are to follow that requirement, then you *cannot *embed `path`=
=20
> >> objects in the return value either, for the same reason you can't use=
=20
> >> `std::string`. Both of them have throwing copy operations (but they ar=
e=20
> >> no-throw moveable). So filesystem_error couldn't be used.=20
> >>=20
> >> Of course you can. Proven by the simple fact people already use and=20
> throw=20
> >> filesystem_error. As long as the copy doesn't *actually* fail=20
> everything's=20
> >> fine. *If* the copy fails do as a throw would and simply terminate=20
> since=20
> >> the two mechanisms are analogous.=20
> >>=20
> > I said "if we are to follow that requirement;" that should not be taken=
=20
> as=20
> > an *endorsement* of said requirement. Obviously `filesystem_error` is a=
=20
> > perfectly functional exception type. My point was that he was talking=
=20
> > elsewhere about adding requirements to `expected` that he hadn't=20
> realized=20
> > would *forbid* the use of `expected<T, filesystem_error>`.=20
> >=20
> Who is he?=20
>
"He" is you from this post.=20
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I9DqVft7qAQ/aEM=
n3UFVAwAJ>=20
Where you explicitly stated that you wanted to forbid the use of error=20
types that could throw on copy. Even to the point of forbidding error types=
=20
that throw on *construction*.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_478_1720227832.1447544243097
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 1:40:46 PM UTC-5, Vicente J. Botet Escrib=
a wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 14/11/2015 18:38, N=
icol Bolas a =C3=A9crit :
<br>> Yeah, kinda. Not just the size of the expected (people can be very=
picky
<br>> about stack space. See discussions about `variant` double-bufferin=
g for an
<br>> example), but also the allocation of memory.
<br>>
<br>> Remember: many users of `expected` operate in contexts where excep=
tions
<br>> simply aren't allowed. And most of those contexts *also* forbi=
d random
<br>> memory allocations. So they would be unable to use `expected` with=
error
<br>> objects that allocate memory. Especially if there were no way to p=
rovide an
<br>> allocator or some other allocation control.
<br>>
<br>> And let's not forget that the space taken up will not be used =
for local
<br>> error handling. Local error handling is *only* interested in the e=
rror
<br>> code, not the paths or string message.
<br>Are you saying that the the adaptation of FileSystem TS to expected=20
<br>couldn't return an filesystem_error?<br></blockquote><div><br>Could=
it? Yes, it could. There is nothing in `expected` that would prevent it.<b=
r><br>My point is that it <i>shouldn't</i>. For the reasons I have expl=
ained at length.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">> This has already been discussed, and no it is not mandatory. Not if =
you
<br>> want to handle the error locally. The path object(s) in the
<br>> `filesystem_error` are data that the local context *already has*. =
So it
<br>> doesn't need them delivered back to them. It only makes sense =
to provide
<br>> that data if you're doing non-local error handling.
<br>>
<br>> This is why FileSystem doesn't have an interface that fills in=
a
<br>> `filesystem_error` by reference. It takes `error_code` by referenc=
e,
<br>> because that's the minimum information that the local context =
needs.
<br>>
<br>> Locally, all you want is an error_code. Only for non-local handlin=
g do you
<br>> want a full `filesystem_error`.
<br>So how would you adapt the FileSystem TS to use expected?<br></blockquo=
te><div><br>Take every function that uses `error_code &ec`. Have it ret=
urn an `expected<T, error_code>` instead.<br><br>Problem solved.<br><=
br>This gives those who want local error handling the minimum information t=
hey need with as little bloat as possible. The syntax is much nicer for the=
m, compared to having to use an output parameter.<br><br>Those who want non=
-local error handling are not affected in the slightest. They call function=
s exactly as before. And users are easily able to switch between them based=
on their needs.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">> =C2=A0=20
<br>>
<br>>> Oh, and I believe you said this on another thread:
<br>>>
<br>>>> If E means Error, we can not throw another error while cop=
ying it.
<br>>> If we are to follow that requirement, then you *cannot *embed =
`path`
<br>>> objects in the return value either, for the same reason you ca=
n't use
<br>>> `std::string`. Both of them have throwing copy operations (but=
they are
<br>>> no-throw moveable). So filesystem_error couldn't be used.
<br>>>
<br>>> Of course you can. Proven by the simple fact people already us=
e and throw
<br>>> filesystem_error. As long as the copy doesn't *actually* f=
ail everything's
<br>>> fine. *If* the copy fails do as a throw would and simply termi=
nate since
<br>>> the two mechanisms are analogous.
<br>>>
<br>> I said "if we are to follow that requirement;" that shou=
ld not be taken as
<br>> an *endorsement* of said requirement. Obviously `filesystem_error`=
is a
<br>> perfectly functional exception type. My point was that he was talk=
ing
<br>> elsewhere about adding requirements to `expected` that he hadn'=
;t realized
<br>> would *forbid* the use of `expected<T, filesystem_error>`.
<br>>
<br>Who is he?
<br></blockquote><div><br><a href=3D"https://groups.google.com/a/isocpp.org=
/d/msg/std-proposals/I9DqVft7qAQ/aEMn3UFVAwAJ">"He" is you from t=
his post.</a> Where you explicitly stated that you wanted to forbid the use=
of error types that could throw on copy. Even to the point of forbidding e=
rror types that throw on <i>construction</i>.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_478_1720227832.1447544243097--
------=_Part_477_1000667835.1447544243097--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 14 Nov 2015 15:39:34 -0800 (PST)
Raw View
------=_Part_658_1820655503.1447544374268
Content-Type: multipart/alternative;
boundary="----=_Part_659_581750441.1447544374269"
------=_Part_659_581750441.1447544374269
Content-Type: text/plain; charset=UTF-8
On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas wrote:
>
> Take every function that uses `error_code &ec`. Have it return an
> `expected<T, error_code>` instead.
>
> Problem solved.
>
Oops. I forgot about the overloading. So you either add `_exp` to the end
of the expected functions, or you add a tag parameter to the expected
function overload to differentiate it.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_659_581750441.1447544374269
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol =
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Take every fu=
nction that uses `error_code &ec`. Have it return an `expected<T, er=
ror_code>` instead.<br><br>Problem solved.<br></div></blockquote><div><b=
r>Oops. I forgot about the overloading. So you either add `_exp` to the end=
of the expected functions, or you add a tag parameter to the expected func=
tion overload to differentiate it.</div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_659_581750441.1447544374269--
------=_Part_658_1820655503.1447544374268--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 15 Nov 2015 02:57:18 +0100
Raw View
Le 15/11/2015 00:37, Nicol Bolas a =C3=A9crit :
> On Saturday, November 14, 2015 at 1:40:46 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>>>
>>> I said "if we are to follow that requirement;" that should not be taken
>> as
>>> an *endorsement* of said requirement. Obviously `filesystem_error` is a
>>> perfectly functional exception type. My point was that he was talking
>>> elsewhere about adding requirements to `expected` that he hadn't
>> realized
>>> would *forbid* the use of `expected<T, filesystem_error>`.
>>>
>> Who is he?
>>
> "He" is you from this post.
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I9DqVft7qAQ/a=
EMn3UFVAwAJ>
> Where you explicitly stated that you wanted to forbid the use of error
> types that could throw on copy. Even to the point of forbidding error typ=
es
> that throw on *construction*.
>
What I mean is that he has a name.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 15 Nov 2015 02:59:26 +0100
Raw View
This is a multi-part message in MIME format.
--------------020708060304030103010508
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 15/11/2015 00:39, Nicol Bolas a =C3=A9crit :
> On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas wrote:
>> Take every function that uses `error_code &ec`. Have it return an
>> `expected<T, error_code>` instead.
>>
>> Problem solved.
>>
> Oops. I forgot about the overloading. So you either add `_exp` to the end
> of the expected functions, or you add a tag parameter to the expected
> function overload to differentiate it.
>
I would like to see a C++ standard proposal :)
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------020708060304030103010508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 15/11/2015 00:39, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:98288b39-5069-4d3b-a4cd-3c3c6505c54d@isocpp.org"
type=3D"cite">
<pre wrap=3D"">On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Ni=
col Bolas wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
Take every function that uses `error_code &ec`. Have it return an=20
`expected<T, error_code>` instead.
Problem solved.
</pre>
</blockquote>
<pre wrap=3D"">
Oops. I forgot about the overloading. So you either add `_exp` to the end=
=20
of the expected functions, or you add a tag parameter to the expected=20
function overload to differentiate it.
</pre>
</blockquote>
<font size=3D"+1">I would like to see a C++ standard proposal :)<br>
<br>
Vicente<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------020708060304030103010508--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 15 Nov 2015 07:19:09 -0800 (PST)
Raw View
------=_Part_1053_1502606072.1447600749851
Content-Type: multipart/alternative;
boundary="----=_Part_1054_1204411119.1447600749851"
------=_Part_1054_1204411119.1447600749851
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, November 14, 2015 at 8:59:28 PM UTC-5, Vicente J. Botet=20
Escriba wrote:
>
> Le 15/11/2015 00:39, Nicol Bolas a =C3=A9crit :
>
> On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas wrote:
>
> Take every function that uses `error_code &ec`. Have it return an=20
> `expected<T, error_code>` instead.
>
> Problem solved.
>
>
> Oops. I forgot about the overloading. So you either add `_exp` to the end=
=20
> of the expected functions, or you add a tag parameter to the expected=20
> function overload to differentiate it.
>
>
> I would like to see a C++ standard proposal :)
>
It wouldn't take you long to build a regex to mechanically transform the=20
FileSystem TS to do that.
That being said, N4109 is not in a sufficiently functional state to start=
=20
suggesting that it be put into other APIs. We still have not resolved the=
=20
questions raised in this thread (unifying exceptions with expected through=
=20
a single function and a special throwing `value`, and if so, how to=20
customize the exception raised by `value`). We have yet to resolve issues=
=20
raised by other threads (`expected` behavior on exceptions, the=20
requirements on T and E). And you're even talking sometimes about allowing=
=20
`expected<T, E1, E2, ...>`.
Until `expected` becomes a more firm and settled proposal itself, there's=
=20
no point in trying to shove it into other APIs. Carts and horses work best=
=20
when placed in the traditional order.
So instead of wanting someone to write a proposal to add `expected`=20
elsewhere, you should be building a revised version of the `expected`=20
proposal that looks into these issues, explains why you make particular=20
design choices, shows what you hope the type will do for other APIs and=20
user error handling, etc.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1054_1204411119.1447600749851
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, November 14, 2015 at 8:59:28 PM UTC-5, Vicent=
e J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 15/11/2015 00:39, Nicol Bolas a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<pre>On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas =
wrote:
</pre>
<blockquote type=3D"cite">
<pre>Take every function that uses `error_code &ec`. Have it re=
turn an=20
`expected<T, error_code>` instead.
Problem solved.
</pre>
</blockquote>
<pre>Oops. I forgot about the overloading. So you either add `_exp` t=
o the end=20
of the expected functions, or you add a tag parameter to the expected=20
function overload to differentiate it.
</pre>
</blockquote>
<font size=3D"+1">I would like to see a C++ standard proposal :)<br></f=
ont></div></blockquote><div><br>It wouldn't take you long to build a re=
gex to mechanically transform the FileSystem TS to do that.<br><br>That bei=
ng said, N4109 is not in a sufficiently functional state to start suggestin=
g that it be put into other APIs. We still have not resolved the questions =
raised in this thread (unifying exceptions with expected through a single f=
unction and a special throwing `value`, and if so, how to customize the exc=
eption raised by `value`). We have yet to resolve issues raised by other th=
reads (`expected` behavior on exceptions, the requirements on T and E). And=
you're even talking sometimes about allowing `expected<T, E1, E2, .=
...>`.<br><br>Until `expected` becomes a more firm and settled proposal i=
tself, there's no point in trying to shove it into other APIs. Carts an=
d horses work best when placed in the traditional order.<br><br>So instead =
of wanting someone to write a proposal to add `expected` elsewhere, you sho=
uld be building a revised version of the `expected` proposal that looks int=
o these issues, explains why you make particular design choices, shows what=
you hope the type will do for other APIs and user error handling, etc.<br>=
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1054_1204411119.1447600749851--
------=_Part_1053_1502606072.1447600749851--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 15 Nov 2015 18:15:09 +0100
Raw View
Le 15/11/2015 16:19, Nicol Bolas a =C3=A9crit :
> On Saturday, November 14, 2015 at 8:59:28 PM UTC-5, Vicente J. Botet
> Escriba wrote:
>> Le 15/11/2015 00:39, Nicol Bolas a =C3=A9crit :
>>
>> On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas wrote:
>>
>> Take every function that uses `error_code &ec`. Have it return an
>> `expected<T, error_code>` instead.
>>
>> Problem solved.
>>
>>
>> Oops. I forgot about the overloading. So you either add `_exp` to the en=
d
>> of the expected functions, or you add a tag parameter to the expected
>> function overload to differentiate it.
>>
>>
>> I would like to see a C++ standard proposal :)
>>
> It wouldn't take you long to build a regex to mechanically transform the
> FileSystem TS to do that.
>
> That being said, N4109 is not in a sufficiently functional state to start
> suggesting that it be put into other APIs.
I was not thinking in N4109. I was think on the simplified expected you=20
are proposing, and that I'll write worst than you.
> We still have not resolved the
> questions raised in this thread (unifying exceptions with expected throug=
h
> a single function and a special throwing `value`, and if so, how to
> customize the exception raised by `value`). We have yet to resolve issues
> raised by other threads (`expected` behavior on exceptions, the
> requirements on T and E). And you're even talking sometimes about allowin=
g
> `expected<T, E1, E2, ...>`.
But you are proposing to have two overloads, isn't it?
>
> Until `expected` becomes a more firm and settled proposal itself, there's
> no point in trying to shove it into other APIs. Carts and horses work bes=
t
> when placed in the traditional order.
But you know what you want from a simple expected proposal, isn't it?
>
> So instead of wanting someone to write a proposal to add `expected`
> elsewhere, you should be building a revised version of the `expected`
> proposal that looks into these issues, explains why you make particular
> design choices, shows what you hope the type will do for other APIs and
> user error handling, etc.
>
But what you proposes has no issues, isn't it? Or have I understood you=20
incorrectly.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 15 Nov 2015 10:19:57 -0800 (PST)
Raw View
------=_Part_1255_307008998.1447611597936
Content-Type: multipart/alternative;
boundary="----=_Part_1256_2094683012.1447611597944"
------=_Part_1256_2094683012.1447611597944
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, November 15, 2015 at 12:15:12 PM UTC-5, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 15/11/2015 16:19, Nicol Bolas a =C3=A9crit :=20
> > On Saturday, November 14, 2015 at 8:59:28 PM UTC-5, Vicente J. Botet=20
> > Escriba wrote:=20
> >> Le 15/11/2015 00:39, Nicol Bolas a =C3=A9crit :=20
> >>=20
> >> On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas wrote:=
=20
> >>=20
> >> Take every function that uses `error_code &ec`. Have it return an=20
> >> `expected<T, error_code>` instead.=20
> >>=20
> >> Problem solved.=20
> >>=20
> >>=20
> >> Oops. I forgot about the overloading. So you either add `_exp` to the=
=20
> end=20
> >> of the expected functions, or you add a tag parameter to the expected=
=20
> >> function overload to differentiate it.=20
> >>=20
> >>=20
> >> I would like to see a C++ standard proposal :)=20
> >>=20
> > It wouldn't take you long to build a regex to mechanically transform th=
e=20
> > FileSystem TS to do that.=20
> >=20
> > That being said, N4109 is not in a sufficiently functional state to=20
> start=20
> > suggesting that it be put into other APIs.=20
> I was not thinking in N4109. I was think on the simplified expected you=
=20
> are proposing, and that I'll write worst than you.
>
I was assuming we were still talking about how to use `expected` with the=
=20
FileSystem TS. That is after all, what you quoted me talking about.
I could write such a proposal. But if you want a preview of what that would=
=20
look like, it would basically be N4109, minus all of the functional stuff=
=20
and any special cases or defaults for `exception_ptr`, and with slightly=20
tighter requirements on E.
That API was more or less fine. What I don't like are many of the=20
directions you keep wanting to move it in (`await` support, multiple error=
=20
code types or implicit variant support, user-specified exceptions on=20
`value`, etc).
=20
> > We still have not resolved the=20
> > questions raised in this thread (unifying exceptions with expected=20
> through=20
> > a single function and a special throwing `value`, and if so, how to=20
> > customize the exception raised by `value`). We have yet to resolve=20
> issues=20
> > raised by other threads (`expected` behavior on exceptions, the=20
> > requirements on T and E). And you're even talking sometimes about=20
> allowing=20
> > `expected<T, E1, E2, ...>`.=20
> But you are proposing to have two overloads, isn't it?=20
>
If you're talking about the FileSystem interface, yes. The problem I want=
=20
`expected` to solve is not the number of overloads that user APIs offer.=20
It's having to use an output parameter to get local error handling.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1256_2094683012.1447611597944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, November 15, 2015 at 12:15:12 PM UTC-5, Vicente J. Botet Escriba=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le 15/11/2015 16:19, Ni=
col Bolas a =C3=A9crit :
<br>> On Saturday, November 14, 2015 at 8:59:28 PM UTC-5, Vicente J. Bot=
et
<br>> Escriba wrote:
<br>>> Le 15/11/2015 00:39, Nicol Bolas a =C3=A9crit :
<br>>>
<br>>> On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bola=
s wrote:
<br>>>
<br>>> Take every function that uses `error_code &ec`. Have it re=
turn an
<br>>> `expected<T, error_code>` instead.
<br>>>
<br>>> Problem solved.
<br>>>
<br>>>
<br>>> Oops. I forgot about the overloading. So you either add `_exp`=
to the end
<br>>> of the expected functions, or you add a tag parameter to the e=
xpected
<br>>> function overload to differentiate it.
<br>>>
<br>>>
<br>>> I would like to see a C++ standard proposal :)
<br>>>
<br>> It wouldn't take you long to build a regex to mechanically tra=
nsform the
<br>> FileSystem TS to do that.
<br>>
<br>> That being said, N4109 is not in a sufficiently functional state t=
o start
<br>> suggesting that it be put into other APIs.
<br>I was not thinking in N4109. I was think on the simplified expected you=
=20
<br>are proposing, and that I'll write worst than you.<br></blockquote>=
<div><br>I was assuming we were still talking about how to use `expected` w=
ith the FileSystem TS. That is after all, what you quoted me talking about.=
<br><br>I could write such a proposal. But if you want a preview of what th=
at would look like, it would basically be N4109, minus all of the functiona=
l stuff and any special cases or defaults for `exception_ptr`, and with sli=
ghtly tighter requirements on E.<br><br>That API was more or less fine. Wha=
t I don't like are many of the directions you keep wanting to move it i=
n (`await` support, multiple error code types or implicit variant support, =
user-specified exceptions on `value`, etc).<br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">> We still have not resolved the
<br>> questions raised in this thread (unifying exceptions with expected=
through
<br>> a single function and a special throwing `value`, and if so, how t=
o
<br>> customize the exception raised by `value`). We have yet to resolve=
issues
<br>> raised by other threads (`expected` behavior on exceptions, the
<br>> requirements on T and E). And you're even talking sometimes ab=
out allowing
<br>> `expected<T, E1, E2, ...>`.
<br>But you are proposing to have two overloads, isn't it?
<br></blockquote><div><br>If you're talking about the FileSystem interf=
ace, yes. The problem I want `expected` to solve is not the number of overl=
oads that user APIs offer. It's having to use an output parameter to ge=
t local error handling.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1256_2094683012.1447611597944--
------=_Part_1255_307008998.1447611597936--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 15 Nov 2015 20:08:05 +0100
Raw View
Le 15/11/2015 19:19, Nicol Bolas a =C3=A9crit :
> On Sunday, November 15, 2015 at 12:15:12 PM UTC-5, Vicente J. Botet Escri=
ba
> wrote:
>> Le 15/11/2015 16:19, Nicol Bolas a =C3=A9crit :
>>> On Saturday, November 14, 2015 at 8:59:28 PM UTC-5, Vicente J. Botet
>>> Escriba wrote:
>>>> Le 15/11/2015 00:39, Nicol Bolas a =C3=A9crit :
>>>>
>>>> On Saturday, November 14, 2015 at 6:37:23 PM UTC-5, Nicol Bolas wrote:
>>>>
>>>> Take every function that uses `error_code &ec`. Have it return an
>>>> `expected<T, error_code>` instead.
>>>>
>>>> Problem solved.
>>>>
>>>>
>>>> Oops. I forgot about the overloading. So you either add `_exp` to the
>> end
>>>> of the expected functions, or you add a tag parameter to the expected
>>>> function overload to differentiate it.
>>>>
>>>>
>>>> I would like to see a C++ standard proposal :)
>>>>
>>> It wouldn't take you long to build a regex to mechanically transform th=
e
>>> FileSystem TS to do that.
>>>
>>> That being said, N4109 is not in a sufficiently functional state to
>> start
>>> suggesting that it be put into other APIs.
>> I was not thinking in N4109. I was think on the simplified expected you
>> are proposing, and that I'll write worst than you.
>>
> I was assuming we were still talking about how to use `expected` with the
> FileSystem TS. That is after all, what you quoted me talking about.
>
> I could write such a proposal. But if you want a preview of what that wou=
ld
> look like, it would basically be N4109, minus all of the functional stuff
> and any special cases or defaults for `exception_ptr`, and with slightly
> tighter requirements on E.
>
> That API was more or less fine. What I don't like are many of the
> directions you keep wanting to move it in (`await` support, multiple erro=
r
> code types or implicit variant support, user-specified exceptions on
> `value`, etc).
> =20
Please go ahead with the simple expected. We will see what could be done=20
later if needed.
>
>>> We still have not resolved the
>>> questions raised in this thread (unifying exceptions with expected
>> through
>>> a single function and a special throwing `value`, and if so, how to
>>> customize the exception raised by `value`). We have yet to resolve
>> issues
>>> raised by other threads (`expected` behavior on exceptions, the
>>> requirements on T and E). And you're even talking sometimes about
>> allowing
>>> `expected<T, E1, E2, ...>`.
>> But you are proposing to have two overloads, isn't it?
>>
> If you're talking about the FileSystem interface, yes. The problem I want
> `expected` to solve is not the number of overloads that user APIs offer.
> It's having to use an output parameter to get local error handling.
>
So you have it. Well the function naming or the tag would not be much=20
supported, but i believe it is worth the effiort.
Good luck,
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 16 Nov 2015 12:20:29 -0500
Raw View
On 2015-11-14 12:38, Nicol Bolas wrote:
> On Saturday, November 14, 2015 at 11:21:09 AM UTC-5, Miro Knejp wrote:
>> Does the size of the exception object really matter in practice? I belie=
ve=20
>> we can all agree that *if* an exception is thrown any performance=20
>> considerations are out the window. The size of the exception object only=
=20
>> really matters in bad_alloc situations which the standard library has to=
=20
>> worry about.
>=20
> Yeah, kinda. Not just the size of the expected (people can be very picky=
=20
> about stack space. See discussions about `variant` double-buffering for a=
n=20
> example), but also the allocation of memory.
>=20
> Remember: many users of `expected` operate in contexts where exceptions=
=20
> simply aren't allowed. And most of those contexts *also* forbid random=20
> memory allocations. So they would be unable to use `expected` with error=
=20
> objects that allocate memory. Especially if there were no way to provide =
an=20
> allocator or some other allocation control.
>=20
> And let's not forget that the space taken up will not be used for local=
=20
> error handling. Local error handling is *only* interested in the error=20
> code, not the paths or string message.
Spitballing...
What we "need" is for lifetime extension that allows the expected to
retain references (ideally in a way that can reuse storage=C2=B9) to the
arguments that were passed into the function that returned the expected,
so that if the error needs to be turned into an exception, those
"temporaries" are still available.
Of course, such a construct would be non-copyable (or would force
copying to turn around and actually make copies of the referenced
arguments).
This *might* be possible with sufficient compiler voodoo, but it feels
like it would have to twist the language into a pretzel ;-).
(=C2=B9 What I mean is that the expected object ideally reuses the storage
that was originally used to pass the parameters rather than inflating
the size of the actual expected object. Which... would actually be quite
easy if we had a purely Forth-like in/out value stack calling
convention. Which we don't, of course, because registers are cheaper
than stack.)
Actually, there's a way to do this that isn't totally convoluted, but
invoking it is ugly... wrap the function that returns expected in one
that either returns the value or throws... Ah, well.
@Miro, I don't think you caught Nicol's earlier point where he
complained about the size of the expected object. Best case, with no
stack allocations (and without a language pretzel), you have lifetime
extension of the input parameters into the returned expected object,
which needs sizeof(void*) =C3=97 number-of-paths. And probably also a
discriminator if those are references to stack memory or pointers to
heap memory, so that the resulting expected object is copyable (best
case, you can lump this into the same discriminator that says if the
expected has a value or an error). All of which, per Nicol's point, is
overhead relative to a "basic" expected<ValueType, ErrorCodeType>, and
is unacceptable to some folks.
--=20
Matthew
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.