Topic: Expected - Request for interest
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 14 Nov 2013 18:36:58 +0100
Raw View
This is a multi-part message in MIME format.
--------------040409010908010703010905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
we are working on a proposal for a Expected class based on
Alexandrescu's talk [1] and following the std::optional proposal [2]
interface . We are considering to
* parameterize the root cause that prevents its creation,
expected<T,E> is either a T or the route cause E that prevents its
creation.
The default type E would be std::exception_ptr as the exceptions seem to
be the most used error-handling mechanism.
There is also some supports for the classes in the <system_error> header.
* make expected default constructible only if T is default
constructible. This would preserve the never-empty guaranty as provided
by boost::variant.
* relational operators following the lexicographic order, first T if
present and then E if there is no value.
* make expected<T,E> a monad. That is, providing bind functions
(then()/recover()) similar to the future<T>::then() function, but
accepting either a function taking the underlying type T for function
then() or the route cause E of the missing value for recover().
* add some convenience factories, as make an expected from the current
exception or from a T value, ...
The current on going implementation is yet incomplete and can be found
at TBoost.Expected [3].
First question: is there any interest in a class expected for the standard?
If yes, what do you think of these additional features?
Best,
Vicente J. Botet Escriba
Pierre Talbot
[1] Systematic Error Handling in C++, Andrei Alexandrescu
http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
[2] "N3793 - A proposal to add a utility class to represent optional
objects (Revision 5)", Fernando Cacciola and Andrzej Krzemien'ski.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html
[3] TBoost.Expected
https://github.com/TrademarkPewPew/Boost.Expected.
--
---
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/.
--------------040409010908010703010905
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi, <br>
<br>
we are working on a proposal for a Expected class based on
Alexandrescu's talk [1] and following the std::optional proposal [2]
interface . We are considering to <br>
<br>
* parameterize the root cause that prevents its creation,
expected<T,E> is either a T or the route cause E that prevents
its creation. <br>
The default type E would be std::exception_ptr as the exceptions
seem to be the most used error-handling mechanism.
<br>
There is also some supports for the classes in the
<system_error> header. <br>
<br>
* make expected default constructible only if T is default
constructible. This would preserve the never-empty guaranty as
provided by boost::variant.<br>
<br>
* relational operators following the lexicographic order, first T
if present and then E if there is no value.<br>
<br>
* make expected<T,E> a monad. That is, providing bind
functions (then()/recover()) similar to the future<T>::then()
function, but accepting either a function taking the underlying type
T for function then() or the route cause E of the missing value for
recover(). <br>
<br>
* add some convenience factories, as make an expected from the
current exception or from a T value, ...<br>
<br>
The current on going implementation is yet incomplete and can be
found at TBoost.Expected [3]. <br>
<br>
First question: is there any interest in a class expected for the
standard? <br>
If yes, what do you think of these additional features? <br>
<br>
Best, <br>
Vicente J. Botet Escriba<br>
Pierre Talbot <br>
<br>
[1] Systematic Error Handling in C++, Andrei Alexandrescu <br>
<br>
<a class="moz-txt-link-freetext"
href="http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C">http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C</a><br>
<br>
[2] “N3793 - A proposal to add a utility class to represent optional
objects (Revision 5)”, Fernando Cacciola and Andrzej Krzemieński. <br>
<br>
<a class="moz-txt-link-freetext"
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html</a><br>
<big><font face="Times New Roman, serif"><font size="3"><big>[3]
TBoost.Expected </big></font></font> </big>
<p><big><a href="https://github.com/TrademarkPewPew/Boost.Expected">https://github.com/TrademarkPewPew/Boost.Expected</a><font
face="Times New Roman, serif"><font size="3"><big><span
lang="en-US">. </span></big></font></font> </big></p>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------040409010908010703010905--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Thu, 14 Nov 2013 10:24:05 -0800
Raw View
--001a11c2f3a64559b004eb2732b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'd like to throw out another idea -- possible integration with something
like error_code. For instance, lets say you have a C++ wrapper around a
system level (POSIX/Windows) API. The API returns an error code, which most
of the time you want to translate into an exception. However, if you do
want the if/else if ladder of error conditions to handle you may want to
avoid constructing an exception and needing to have throwing / catching
perf penalties that were inherent in the expected<T> design.
Could this easily be expanded into something that contains A. a T, B. an
exception_ptr, or C. an error_code, and translates the error_code into an
exception if callers try to access T directly?
If not, would it make sense to have a separate type which did this?
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Thu, Nov 14, 2013 at 9:36 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> we are working on a proposal for a Expected class based on Alexandrescu's
> talk [1] and following the std::optional proposal [2] interface . We are
> considering to
>
> * parameterize the root cause that prevents its creation, expected<T,E>
> is either a T or the route cause E that prevents its creation.
> The default type E would be std::exception_ptr as the exceptions seem to
> be the most used error-handling mechanism.
> There is also some supports for the classes in the <system_error> header.
>
> * make expected default constructible only if T is default constructible=
..
> This would preserve the never-empty guaranty as provided by boost::varian=
t.
>
> * relational operators following the lexicographic order, first T if
> present and then E if there is no value.
>
> * make expected<T,E> a monad. That is, providing bind functions
> (then()/recover()) similar to the future<T>::then() function, but accepti=
ng
> either a function taking the underlying type T for function then() or the
> route cause E of the missing value for recover().
>
> * add some convenience factories, as make an expected from the current
> exception or from a T value, ...
>
> The current on going implementation is yet incomplete and can be found at
> TBoost.Expected [3].
>
> First question: is there any interest in a class expected for the
> standard?
> If yes, what do you think of these additional features?
>
> Best,
> Vicente J. Botet Escriba
> Pierre Talbot
>
> [1] Systematic Error Handling in C++, Andrei Alexandrescu
>
>
> http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexan=
drescu-Systematic-Error-Handling-in-C
>
> [2] =E2=80=9CN3793 - A proposal to add a utility class to represent optio=
nal
> objects (Revision 5)=E2=80=9D, Fernando Cacciola and Andrzej Krzemie=C5=
=84ski.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3793.html
> [3] TBoost.Expected
>
> https://github.com/TrademarkPewPew/Boost.Expected.
>
> --
>
> ---
> 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/.
--001a11c2f3a64559b004eb2732b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'd like to throw out another idea -- possible in=
tegration with something like error_code. For instance, lets say you have a=
C++ wrapper around a system level (POSIX/Windows)=C2=A0API. The API return=
s an error code, which most of the time you want to translate into an excep=
tion. However, if you do want the if/else if ladder of error conditions to =
handle you may want to avoid constructing an exception and needing to have =
throwing / catching perf penalties that were inherent in the expected<T&=
gt; design.</div>
<div>=C2=A0</div><div>Could this easily be expanded into something that con=
tains A. a T, B. an exception_ptr, or C. an error_code, and translates the =
error_code into an exception if callers=C2=A0try to access T directly?</div=
><div>
=C2=A0</div><div>If not, would it make sense to have a separate type which =
did this?</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div=
dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https://bitbucket.o=
rg/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Nov 14, 2013 at 9:36 AM, Vicente=
J. Botet Escriba <span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wan=
adoo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
Hi, <br>
<br>
we are working on a proposal for a Expected class based on
Alexandrescu's talk [1] and following the std::optional proposal [2=
]
interface . We are considering to <br>
<br>
=C2=A0* parameterize the root cause that prevents its creation,
expected<T,E> is either a T or the route cause E that prevents
its=C2=A0 creation. <br>
The default type E would be std::exception_ptr as the exceptions
seem to be the most used error-handling mechanism.
<br>
There is also some supports for the classes in the
<system_error> header. <br>
<br>
=C2=A0* make expected default constructible only if T is default
constructible. This would preserve the never-empty guaranty as
provided by boost::variant.<br>
<br>
=C2=A0* relational operators following the lexicographic order, first T
if present and then E if there is no value.<br>
<br>
=C2=A0* make expected<T,E> a monad. That is, providing bind
functions (then()/recover()) similar to the future<T>::then()
function, but accepting either a function taking the underlying type
T for function then() or the route cause E of the missing value for
recover(). <br>
<br>
=C2=A0* add some convenience factories, as make an expected from the
current exception or from a T value, ...<br>
<br>
The current on going implementation is yet incomplete and can be
found at TBoost.Expected [3]. <br>
<br>
First question: is there any interest in a class expected for the
standard? <br>
If yes, what do you think of these additional features? <br>
<br>
Best, <br>
Vicente J. Botet Escriba<br>
Pierre Talbot <br>
<br>
[1] Systematic Error Handling in C++, Andrei Alexandrescu <br>
<br>
<a href=3D"http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-=
Andrei-Alexandrescu-Systematic-Error-Handling-in-C" target=3D"_blank">http:=
//channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-=
Systematic-Error-Handling-in-C</a><br>
=C2=A0<br>
[2] =E2=80=9CN3793 - A proposal to add a utility class to represent opt=
ional
objects (Revision 5)=E2=80=9D, Fernando Cacciola and Andrzej Krzemie=C5=
=84ski. <br>
<br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n379=
3.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2013/n3793.html</a><br>
<big><font face=3D"Times New Roman, serif"><font size=3D"3"><big>[3]
TBoost.Expected </big></font></font> </big>
<p><big><a href=3D"https://github.com/TrademarkPewPew/Boost.Expected" t=
arget=3D"_blank">https://github.com/TrademarkPewPew/Boost.Expected</a><font=
face=3D"Times New Roman, serif"><font size=3D"3"><big><span lang=3D"en-US"=
>. </span></big></font></font><span class=3D"HOEnZb"><font color=3D"#888888=
"> </font></span></big></p>
<span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=C2=A0<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2f3a64559b004eb2732b5--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 14 Nov 2013 21:39:51 +0200
Raw View
On 14 November 2013 19:36, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> we are working on a proposal for a Expected class based on Alexandrescu's
> talk [1] and following the std::optional proposal [2] interface . We are
> considering to
>
> * parameterize the root cause that prevents its creation, expected<T,E> is
> either a T or the route cause E that prevents its creation.
> The default type E would be std::exception_ptr as the exceptions seem to be
> the most used error-handling mechanism.
> There is also some supports for the classes in the <system_error> header.
>
> * make expected default constructible only if T is default constructible.
> This would preserve the never-empty guaranty as provided by boost::variant.
>
> * relational operators following the lexicographic order, first T if
> present and then E if there is no value.
>
> * make expected<T,E> a monad. That is, providing bind functions
> (then()/recover()) similar to the future<T>::then() function, but accepting
> either a function taking the underlying type T for function then() or the
> route cause E of the missing value for recover().
>
> * add some convenience factories, as make an expected from the current
> exception or from a T value, ...
>
> The current on going implementation is yet incomplete and can be found at
> TBoost.Expected [3].
>
> First question: is there any interest in a class expected for the standard?
> If yes, what do you think of these additional features?
I have heard SG1 members mention that they need a library type that
holds a value
or an error. This 'expected' type sounds quite similar to that, so it
would be beneficial
to check with SG1 about guidance and scope.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 14 Nov 2013 22:21:58 +0100
Raw View
This is a multi-part message in MIME format.
--------------030800010204090707020301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 14/11/13 19:24, Billy O'Neal a =E9crit :
> I'd like to throw out another idea -- possible integration with=20
> something like error_code. For instance, lets say you have a C++=20
> wrapper around a system level (POSIX/Windows) API. The API returns an=20
> error code, which most of the time you want to translate into an=20
> exception. However, if you do want the if/else if ladder of error=20
> conditions to handle you may want to avoid constructing an exception=20
> and needing to have throwing / catching perf penalties that were=20
> inherent in the expected<T> design.
We propose to have a template parameter for the Exceptional type.
template <class ValueType, class ExceptionalType=3D exception_ptr>
Of course this can be std::error_condition, std::error_code or what ever=20
you want.
> Could this easily be expanded into something that contains A. a T, B.=20
> an exception_ptr, or C. an error_code, and translates the error_code=20
> into an exception if callers try to access T directly?
Our idea was to have either a T or an E, where E could be exception_ptr=20
or error_code. Any type E different from exception_ptr would result on a=20
bad_expected_access exception thrown when caller try to access an=20
expected that has an error stored. This is in line with=20
std::experimental::optional.
with the recover() function, you would be able to do the following
auto x =3D my_expected_int_factory().recover([](e) { throw MyException(e); =
}
// here we are sure that x contains an int
Of course this could be cumbersome if needed a lot, but the user could=20
define a template function that that do it
template <class Exception, class T, class Error, >
T GetOrThrow(expected<T,Error>&& v) {
if e.valid() return v;
else throw Exception(v.error());
}
the user could use it as
auto i =3D GetOrThrow<MyException>(my_expected_int_factory());
> If not, would it make sense to have a separate type which did this?
Of course if others think that the extension is a must have we could=20
explore some alternatives.
Thanks for your comments,
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/.
--------------030800010204090707020301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 14/11/13 19:24, Billy O'Neal a
écrit :<br>
</div>
<blockquote
cite=3D"mid:CAPBZbvyE8U-RmTM5zXNw6BCaJRdB2yvPX7Kz8nyChFuL-zZfPA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div>I'd like to throw out another idea -- possible integration
with something like error_code. For instance, lets say you
have a C++ wrapper around a system level (POSIX/Windows) API=
..
The API returns an error code, which most of the time you want
to translate into an exception. However, if you do want the
if/else if ladder of error conditions to handle you may want
to avoid constructing an exception and needing to have
throwing / catching perf penalties that were inherent in the
expected<T> design.</div>
</div>
</blockquote>
We propose to have a template parameter for the Exceptional type. <br>
<br>
<meta http-equiv=3D"content-type" content=3D"text/html;
charset=3DISO-8859-1">
<pre><div class=3D"line" id=3D"LC141"> <span class=3D"k">tem=
plate</span> <span class=3D"o"><</span><span class=3D"k">class</span> <s=
pan class=3D"n">ValueType</span><span class=3D"p">,</span> <span class=3D"k=
">class</span> <span class=3D"n">ExceptionalType</span><span class=3D"o"> =
=3D </span><span class=3D"n">exception_ptr</span><span class=3D"o">></sp=
an></div></pre>
<br>
Of course this can be std::error_condition, std::error_code or what
ever you want.<br>
<blockquote
cite=3D"mid:CAPBZbvyE8U-RmTM5zXNw6BCaJRdB2yvPX7Kz8nyChFuL-zZfPA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div> </div>
<div>Could this easily be expanded into something that contains
A. a T, B. an exception_ptr, or C. an error_code, and
translates the error_code into an exception if callers try t=
o
access T directly?</div>
</div>
</blockquote>
Our idea was to have either a T or an E, where E could be
exception_ptr or error_code. Any type E different from exception_ptr
would result on a bad_expected_access exception thrown when caller
try to access an expected that has an error stored. This is in line
with std::experimental::optional.<br>
<br>
with the recover() function, you would be able to do the following<br>
<br>
auto x =3D my_expected_int_factory().recover([](e) { throw
MyException(e); } <br>
// here we are sure that x contains an int<br>
<br>
Of course this could be cumbersome if needed a lot, but the user
could define a template function that that do it<br>
<br>
template <class Exception, class T, class Error, ><br>
T GetOrThrow(expected<T,Error>&& v) {<br>
if e.valid() return v; <br>
else throw Exception(v.error());<br>
}<br>
<br>
the user could use it as <br>
<br>
auto i =3D GetOrThrow<MyException>(my_expected_int_factory());&nb=
sp;
<br>
<br>
<br>
<br>
<blockquote
cite=3D"mid:CAPBZbvyE8U-RmTM5zXNw6BCaJRdB2yvPX7Kz8nyChFuL-zZfPA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div>If not, would it make sense to have a separate type which
did this?</div>
</div>
</blockquote>
Of course if others think that the extension is a must have we could
explore some alternatives.<br>
<br>
Thanks for your comments,<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------030800010204090707020301--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 14 Nov 2013 22:27:48 +0100
Raw View
Le 14/11/13 20:39, Ville Voutilainen a =E9crit :
> On 14 November 2013 19:36, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Hi,
>>
>> we are working on a proposal for a Expected class based on Alexandrescu'=
s
>> talk [1] and following the std::optional proposal [2] interface .
>
>
> I have heard SG1 members mention that they need a library type that
> holds a value
> or an error. This 'expected' type sounds quite similar to that, so it
> would be beneficial
> to check with SG1 about guidance and scope.
>
Hi Ville,
thanks for the information. We will post to SG1 ML. maybe you can give=20
some feedback about the points we are considering.
Best,
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/.
.