Topic: N4015: A proposal to add a utility class to
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 24 May 2014 13:19:39 +0200
Raw View
This is a multi-part message in MIME format.
--------------090906000103080601000203
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/05/14 11:46, Ivan =C4=8Cuki=C4=87 a =C3=A9crit :
> Hi,
>
> Love the general idea. Was planning to propose it myself. I didn't go=20
> into details, so just a few general comments for the proposal.
>
Hi,
> 1.
> The main issue I have with it is the order of <E, T>. In the haskell's=20
> error monad [1] the name implies that it is about errors, and the=20
> first argument is the error type.
>
in [1] ErrorT is a n error monad transformer that takes an error e and=20
another monad m. expected doesn't takes an error type and a monad, but a=20
type.
expected<E,T> could be equivalent as ErrorT<E, expected_tc<E>, T> for=20
some expected_tc type constructor (see below).
> This is the other side of the same coin, for 'expected' I'd expect the=20
> first argument to be the expected type.
>
> Exchanging the types would also allow to specify the default value of=20
> E to be std::exception_ptr.
>
> |
> template<typenameT,typenameE =3Dstd::exception_ptr>
> classexpected {...};
> |
>
> Otherwise, people will rather opt in to use std::optional<T> because=20
> it is easier to write, and does not pollute the code.
>
The original class was defined just as you propose. We moved to the=20
current expected<E,T> form to be able to write
auto e =3D expected<error_condition>::make(1) // result is=20
expected<error_condition, int>
Others have already do the same remark, and we would not have any=20
problem rolling back to the original design. We will need a different=20
type constructor expected_tc (a better name of course)
auto e =3D expected_tc<error_condition>::make(1) // result is=20
expected<error_condition, int>
> 2.
> As for fmap, this will start the non-generic way of naming. futures=20
> have .then, this will have .fmap (and .then?), who knows how the next=20
> monad will name its bind operator. (IMO, this should be a part of=20
> another proposal, along with the all the stuff that require new=20
> core-language things like <-, and catch_exception {})
We have already renamed fmap to map and mbind to bind as requested in=20
C++Now 2014.
I have no problem in separating it into two proposals, one that address=20
the minimal interface of expected and one another that address the=20
monadic functions. The problem I have is that I don't know how to=20
address the concept of Monad with the current C++ language. Non-members=20
functions seem to don't address the problem correctly as commented by=20
Sebastian Redl in an other post.
Defining the functions as members has its own limitations, but at least=20
it allows to build on top of all the classes classes defining a similar=20
interface.
We could add the member functions map/bind/catch_error to optional<T>=20
and future<T> without too much difficulties. The same could apply to any=20
std container class, but we couldn't see T* or T[N] as a Monad.
>
> 3.
> Unexpect sounds strange :)
>
What do you find strange? Do you mean that it sounds strange in English?
Pierre has suggested that we could replace unexpect
expected<E,T> e =3D {unexpect, a1, an};
by
expected<E,T> e =3D unexpeted_type{in_place, a1, an};
This would mean a in place constructor of the unexpected value and a=20
move to the expected storage.
Vicente
P.S. Note that the proposal use unexpeted_type as unexpected is already=20
used in the standard.
>
> [1] https://hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-Er=
ror.html
>
--=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/.
--------------090906000103080601000203
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 24/05/14 11:46, Ivan =C4=8Cuki=C4=87 =
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">Hi,
<div><br>
</div>
<div>Love the general idea. Was planning to propose it myself. I
didn't go into details, so just a few general comments for the
proposal.</div>
<div><br>
</div>
</div>
</blockquote>
Hi,<br>
<blockquote
cite=3D"mid:94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>1.</div>
<div>The main issue I have with it is the order of <E, T>.
In the haskell's error monad [1] the name implies that it is
about errors, and the first argument is the error type.</div>
<div><br>
</div>
</div>
</blockquote>
in [1] ErrorT is a n error monad transformer that takes an error e
and another monad m. expected doesn't takes an error type and a
monad, but a type. <br>
<br>
expected<E,T> could be equivalent as ErrorT<E,
expected_tc<E>, T> for some expected_tc type constructor
(see below).<br>
=C2=A0 <br>
<blockquote
cite=3D"mid:94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>This is the other side of the same coin, for 'expected' I'd
expect the first argument to be the expected type.</div>
<div><br>
</div>
<div>Exchanging the types would also allow to specify the
default value of E to be std::exception_ptr.</div>
<div>
<div><br>
</div>
<div class=3D"prettyprint" style=3D"background-color: rgb(250,
250, 250); border: 1px solid rgb(187, 187, 187); word-wrap:
break-word;"><code class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">template</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> T</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> E </=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> std<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify">excep=
tion_ptr</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">class</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">
expected </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
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan></div>
</code></div>
<div><br>
</div>
</div>
<div>Otherwise, people will rather opt in to use
std::optional<T> because it is easier to write, and does
not pollute the code.</div>
<div><br>
</div>
</div>
</blockquote>
The original class was defined just as you propose. We moved to the
current expected<E,T> form to be able to write<br>
<br>
auto e=C2=A0 =3D expected<error_condition>::make(1) // result is
expected<error_condition, int><br>
<br>
Others have already do the same remark, and we would not have any
problem rolling back to the original design. We will need a
different type constructor expected_tc (a better name of course)<br>
<br>
auto e=C2=A0 =3D expected_tc<error_condition>::make(1) // result =
is
expected<error_condition, int><br>
<br>
<blockquote
cite=3D"mid:94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>2.</div>
<div>As for fmap, this will start the non-generic way of naming.
futures have .then, this will have .fmap (and .then?), who
knows how the next monad will name its bind operator. (IMO,
this should be a part of another proposal, along with the all
the stuff that require new core-language things like <-,
and catch_exception {})</div>
</div>
</blockquote>
<br>
We have already renamed fmap to map and mbind to bind as requested
in C++Now 2014.<br>
<br>
I have no problem in separating it into two proposals, one that
address the minimal interface of expected and one another that
address the monadic functions. The problem I have is that I don't
know how to address the concept of Monad with the current C++
language. Non-members functions seem to don't address the problem
correctly as commented by Sebastian Redl in an other post.<br>
<br>
Defining the functions as members has its own limitations, but at
least it allows to build on top of all the classes classes defining
a similar interface.<br>
<br>
We could add the member functions map/bind/catch_error to
optional<T> and future<T> without too much difficulties.
The same could apply to any std container class, but we couldn't see
T* or T[N] as a Monad.<br>
<blockquote
cite=3D"mid:94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>3.</div>
<div>Unexpect sounds strange :)</div>
<div><br>
</div>
</div>
</blockquote>
What do you find strange? Do you mean that it sounds strange in
English?<br>
<br>
Pierre has suggested that we could replace unexpect <br>
<br>
expected<E,T> e =3D {unexpect, a1, an};<br>
<br>
by<br>
<br>
expected<E,T> e =3D unexpeted_type{in_place, a1, an};<br>
<br>
This would mean a in place constructor of the unexpected value and a
move to the expected storage.<br>
<br>
<br>
Vicente<br>
<br>
P.S. Note that the proposal use unexpeted_type as unexpected is
already used in the standard.<br>
<blockquote
cite=3D"mid:94ded66f-1c50-47b9-8a04-b83805443da9@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<div>[1]=C2=A0<a class=3D"moz-txt-link-freetext" href=3D"https://ha=
ckage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-Error.html">https:=
//hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-Error.html</a>=
</div>
</div>
<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 />
--------------090906000103080601000203--
.
Author: =?UTF-8?Q?Ivan_=C4=8Cuki=C4=87?= <ivan.cukic@gmail.com>
Date: Sat, 24 May 2014 08:58:19 -0700 (PDT)
Raw View
------=_Part_132_10615477.1400947099873
Content-Type: text/plain; charset=UTF-8
I guess you have considered a lot of different options.
Is there a publicly accessible log of the discussions? Otherwise I have no
choice but to bother you with more questions. :)
> in [1] ErrorT is a n error monad transformer that takes an error e and
> another monad m. expected doesn't takes an error type and a monad, but a
> type.
>
Yes, but I hope you got my point regarding the naming. I'd rather that the
api caters to the "happy path" (to quote E. Meijer) than to the failure
cases.
> The original class was defined just as you propose. We moved to the
> current expected<E,T> form to be able to write
>
> auto e = expected<error_condition>::make(1) // result is
> expected<error_condition, int>
>
What is the use-case for the above that can not be rewritten using the
implicit construction or make_expected (unfortunately, pdf doesn't contain
much details for make_expected), and that would significantly benefit from
not writing expected<int, error_condition>(1)?
What about make_expected(T value) -> expected<T, void> which would
implicitly convert to expected<T, AnyType>? I don't see the necessity of
make_expected to always use exception_ptr.
> Others have already do the same remark, and we would not have any problem
> rolling back to the original design. We will need a different type
> constructor expected_tc (a better name of course)
>
If it is necessary, +1.
We have already renamed fmap to map and mbind to bind as requested in
> C++Now 2014.
>
Cool. :)
I have no problem in separating it into two proposals, one that address the
> minimal interface of expected and one another that address the monadic
> functions.
>
I'd really advise that approach - it would be a shame if the expected<...>
class would get rejected or its inclusion postponed because of the other
parts of the proposal needed polishing.
> The problem I have is that I don't know how to address the concept of
> Monad with the current C++ language. Non-members functions seem to don't
> address the problem correctly as commented by Sebastian Redl in an other
> post.
>
There is a dead thread that Vicente Escriba started some time ago:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z5yZkJ
And yes, making Monads will be painful.
> We could add the member functions map/bind/catch_error to optional<T> and
> future<T> without too much difficulties. The same could apply to any std
> container class, but we couldn't see T* or T[N] as a Monad.
>
Maybe it could follow the same approach as member and non-member begin/end.
Though, in all honesty, I don't really care about raw pointers and arrays.
> What do you find strange? Do you mean that it sounds strange in English?
>
Yes, the word is not recognized by Merriam-Webster nor Oxford dictionary.
But this is more of a nit-pick than anything else.
Cheerio, and thanks for the quick response!
Ivan
--
---
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_132_10615477.1400947099873
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I guess you have considered a lot of different option=
s.</div><div><br></div><div>Is there a publicly accessible log of the discu=
ssions? Otherwise I have no choice but to bother you with more questions. :=
)</div><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">in [1] ErrorT is a n error monad transf=
ormer that takes an error e
and another monad m. expected doesn't takes an error type and a
monad, but a type. <br></div></blockquote><div><br></div><div>Yes, but =
I hope you got my point regarding the naming. I'd rather that the api cater=
s to the "happy path" (to quote E. Meijer) than to the failure cases.</div>=
<div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">The original class was defined just as you pr=
opose. We moved to the
current expected<E,T> form to be able to write<br>
<br>
auto e =3D expected<error_condition>::<wbr>make(1) // resul=
t is
expected<error_condition, int><br></div></blockquote><div><br></d=
iv><div>What is the use-case for the above that can not be rewritten using =
the implicit construction or make_expected (unfortunately, pdf doesn't cont=
ain much details for make_expected), and that would significantly benefit f=
rom not writing expected<int, error_condition>(1)?<br><br>What about =
make_expected(T value) -> expected<T, void> which would implicitly=
convert to expected<T, AnyType>? I don't see the necessity of make_e=
xpected to always use exception_ptr.</div><div> </div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
Others have already do the same remark, and we would not have any
problem rolling back to the original design. We will need a
different type constructor expected_tc (a better name of course)<br></d=
iv></blockquote><div><br></div><div>If it is necessary, +1.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" =
text=3D"#000000">We have already renamed fmap to map and mbind to bind as r=
equested
in C++Now 2014.<br></div></blockquote><div> </div><div>Cool. :)&nb=
sp;</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">
I have no problem in separating it into two proposals, one that
address the minimal interface of expected and one another that
address the monadic functions.</div></blockquote><div><br></div><div>I'=
d really advise that approach - it would be a shame if the expected<...&=
gt; class would get rejected or its inclusion postponed because of the othe=
r parts of the proposal needed polishing.</div><div> </div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000"=
> The problem I have is that I don't
know how to address the concept of Monad with the current C++
language. Non-members functions seem to don't address the problem
correctly as commented by Sebastian Redl in an other post.<br></div></b=
lockquote><div><br>There is a dead thread that Vicente Escriba started some=
time ago: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwE=
q49GMA/a5f117Z5yZkJ<br><br></div><div>And yes, making Monads will be painfu=
l.</div><div> </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">We could add the member functions map/=
bind/catch_error to
optional<T> and future<T> without too much difficulties.
The same could apply to any std container class, but we couldn't see
T* or T[N] as a Monad.<br></div></blockquote><div><br></div><div>Maybe =
it could follow the same approach as member and non-member begin/end. Thoug=
h, in all honesty, I don't really care about raw pointers and arrays.</div>=
<div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div dir=3D"ltr"><d=
iv>
</div>
</div></blockquote>What do you find strange? Do you mean that it so=
unds strange in
English?<br></div></blockquote><div> </div><div>Yes, the word is n=
ot recognized by Merriam-Webster nor Oxford dictionary. But this is more of=
a nit-pick than anything else.</div><div><br></div><div><span style=3D"fon=
t-size: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">Cheer=
io, and thanks for the quick response!</span></div><div><span style=3D"font=
-size: 13px;">Ivan</span></div><div><span style=3D"font-size: 13px;"><br></=
span></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_132_10615477.1400947099873--
.
Author: =?UTF-8?Q?Ivan_=C4=8Cuki=C4=87?= <ivan.cukic@gmail.com>
Date: Sat, 24 May 2014 11:32:28 -0700 (PDT)
Raw View
------=_Part_417_31222811.1400956348856
Content-Type: text/plain; charset=UTF-8
>
>
> There is a dead thread that Vicente Escriba started some time ago:
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z5yZkJ
>
>
And I actually didn't realize that I linked a thread that you have started
:)
Cheers!
--
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76
--
---
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_417_31222811.1400956348856
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>There is a dead thread that Vicente Escriba started some time =
ago: <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/=
KCqwEq49GMA/a5f117Z5yZkJ" target=3D"_blank" onmousedown=3D"this.href=3D'htt=
ps://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z=
5yZkJ';return true;" onclick=3D"this.href=3D'https://groups.google.com/a/is=
ocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z5yZkJ';return true;">https:=
//groups.google.com/a/<wbr>isocpp.org/d/msg/std-<wbr>proposals/KCqwEq49GMA/=
<wbr>a5f117Z5yZkJ</a><br><br></div></div></blockquote><div><br></div><div>A=
nd I actually didn't realize that I linked a thread that you have started :=
) </div><div><br></div><div>Cheers!</div><div><br></div><div><br></div=
><div>
<p style=3D"margin-bottom: 0px;"><!--StartFragment-->-- </p>
<p style=3D"margin-bottom: 0px;">KDE, ivan.cukic at kde.org, http://ivan.fo=
mentgroup.org/ </p>
<p style=3D"margin-bottom: 0px;">gpg key id: 850B6F76<!--EndFragment--></p>=
</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 />
------=_Part_417_31222811.1400956348856--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 25 May 2014 11:49:26 +0200
Raw View
This is a multi-part message in MIME format.
--------------000306040301030003010009
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/05/14 17:58, Ivan =C4=8Cuki=C4=87 a =C3=A9crit :
> I guess you have considered a lot of different options.
>
> Is there a publicly accessible log of the discussions? Otherwise I=20
> have no choice but to bother you with more questions. :)
>
> in [1] ErrorT is a n error monad transformer that takes an error e
> and another monad m. expected doesn't takes an error type and a
> monad, but a type.
>
>
> Yes, but I hope you got my point regarding the naming. I'd rather that=20
> the api caters to the "happy path" (to quote E. Meijer) than to the=20
> failure cases.
Yes i did.
>
> The original class was defined just as you propose. We moved to
> the current expected<E,T> form to be able to write
>
> auto e =3D expected<error_condition>::make(1) // result is
> expected<error_condition, int>
>
>
> What is the use-case for the above that can not be rewritten using the=20
> implicit construction or make_expected (unfortunately, pdf doesn't=20
> contain much details for make_expected), and that would significantly=20
> benefit from not writing expected<int, error_condition>(1)?
>
> What about make_expected(T value) -> expected<T, void> which would=20
> implicitly convert to expected<T, AnyType>? I don't see the necessity=20
> of make_expected to always use exception_ptr.
We have already un implicit conversion from T to expected<E,T>. The=20
reason for make_expected is to be explicit enough to have a uniqye type=20
as result.
>
> Others have already do the same remark, and we would not have any
> problem rolling back to the original design. We will need a
> different type constructor expected_tc (a better name of course)
>
>
> If it is necessary, +1.
>
> We have already renamed fmap to map and mbind to bind as requested
> in C++Now 2014.
>
> Cool. :)
>
> I have no problem in separating it into two proposals, one that
> address the minimal interface of expected and one another that
> address the monadic functions.
>
>
> I'd really advise that approach - it would be a shame if the=20
> expected<...> class would get rejected or its inclusion postponed=20
> because of the other parts of the proposal needed polishing.
I would have no problem, however we are a little bit too late to change=20
it for Raspewill.
>
> The problem I have is that I don't know how to address the concept
> of Monad with the current C++ language. Non-members functions seem
> to don't address the problem correctly as commented by Sebastian
> Redl in an other post.
>
>
> There is a dead thread that Vicente Escriba started some time ago:=20
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5=
f117Z5yZkJ
>
Yes this Vicente is me.
> And yes, making Monads will be painful.
>
> We could add the member functions map/bind/catch_error to
> optional<T> and future<T> without too much difficulties. The same
> could apply to any std container class, but we couldn't see T* or
> T[N] as a Monad.
>
>
> Maybe it could follow the same approach as member and non-member=20
> begin/end. Though, in all honesty, I don't really care about raw=20
> pointers and arrays.
Maybe.
- Would this mean that we have to add the map/bins/cacth_error/unit as=20
member functions and that the default forwards to members functions?
- non-member functions don't chain as well as member functions.
- we will need infix operators
>
> What do you find strange? Do you mean that it sounds strange in
> English?
>
> Yes, the word is not recognized by Merriam-Webster nor Oxford=20
> dictionary. But this is more of a nit-pick than anything else.
>
Oh I understand why you find it estrange now :(
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/.
--------------000306040301030003010009
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 24/05/14 17:58, Ivan =C4=8Cuki=C4=87 =
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>I guess you have considered a lot of different options.</div>
<div><br>
</div>
<div>Is there a publicly accessible log of the discussions?
Otherwise I have no choice but to bother you with more
questions. :)</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;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">in [1] ErrorT is a n
error monad transformer that takes an error e and another
monad m. expected doesn't takes an error type and a monad,
but a type. <br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, but I hope you got my point regarding the naming. I'd
rather that the api caters to the "happy path" (to quote E.
Meijer) than to the failure cases.</div>
</div>
</blockquote>
Yes i did.<br>
<blockquote
cite=3D"mid:0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<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">The original class was
defined just as you propose. We moved to the current
expected<E,T> form to be able to write<br>
<br>
auto e=C2=A0 =3D expected<error_condition>::<wbr>make(1) =
//
result is expected<error_condition, int><br>
</div>
</blockquote>
<div><br>
</div>
<div>What is the use-case for the above that can not be
rewritten using the implicit construction or make_expected
(unfortunately, pdf doesn't contain much details for
make_expected), and that would significantly benefit from not
writing expected<int, error_condition>(1)?<br>
<br>
What about make_expected(T value) -> expected<T,
void> which would implicitly convert to expected<T,
AnyType>? I don't see the necessity of make_expected to
always use exception_ptr.</div>
</div>
</blockquote>
We have already un implicit conversion from T to
expected<E,T>. The reason for make_expected is to be explicit
enough to have a uniqye type as result.<br>
<blockquote
cite=3D"mid:0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<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"> Others have already do
the same remark, and we would not have any problem rolling
back to the original design. We will need a different type
constructor expected_tc (a better name of course)<br>
</div>
</blockquote>
<div><br>
</div>
<div>If it is necessary, +1.</div>
<div><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"#FFFFFF" text=3D"#000000">We have already renamed
fmap to map and mbind to bind as requested in C++Now 2014.<br>
</div>
</blockquote>
<div>=C2=A0</div>
<div>Cool. :)=C2=A0</div>
<div><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"#FFFFFF" text=3D"#000000"> I have no problem in
separating it into two proposals, one that address the
minimal interface of expected and one another that address
the monadic functions.</div>
</blockquote>
<div><br>
</div>
<div>I'd really advise that approach - it would be a shame if
the expected<...> class would get rejected or its
inclusion postponed because of the other parts of the proposal
needed polishing.</div>
</div>
</blockquote>
I would have no problem, however we are a little bit too late to
change it for Raspewill.<br>
<blockquote
cite=3D"mid:0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<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"> The problem I have is
that I don't know how to address the concept of Monad with
the current C++ language. Non-members functions seem to
don't address the problem correctly as commented by
Sebastian Redl in an other post.<br>
</div>
</blockquote>
<div><br>
There is a dead thread that Vicente Escriba started some time
ago:
<a class=3D"moz-txt-link-freetext" href=3D"https://groups.google.com/a/isoc=
pp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z5yZkJ">https://groups.google.=
com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f117Z5yZkJ</a><br>
<br>
</div>
</div>
</blockquote>
Yes this Vicente is me.<br>
<blockquote
cite=3D"mid:0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>And yes, making Monads will be painful.</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;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">We could add the member
functions map/bind/catch_error to optional<T> and
future<T> without too much difficulties. The same
could apply to any std container class, but we couldn't see
T* or T[N] as a Monad.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Maybe it could follow the same approach as member and
non-member begin/end. Though, in all honesty, I don't really
care about raw pointers and arrays.</div>
</div>
</blockquote>
Maybe. <br>
- Would this mean that we have to add the map/bins/cacth_error/unit
as member functions and that the default forwards to members
functions?<br>
- non-member functions don't chain as well as member functions.<br>
- we will need infix operators<br>
<blockquote
cite=3D"mid:0e4dbb0e-0a7e-4164-be4e-60e114b18548@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<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 dir=3D"ltr">
<div> </div>
</div>
</blockquote>
What do you find strange? Do you mean that it sounds strange
in English?<br>
</div>
</blockquote>
<div>=C2=A0</div>
<div>Yes, the word is not recognized by Merriam-Webster nor
Oxford dictionary. But this is more of a nit-pick than
anything else.</div>
<br>
</div>
</blockquote>
Oh I understand why you find it estrange now :(<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 />
--------------000306040301030003010009--
.
Author: Ivan =?utf-8?B?xIx1a2nEhw==?= <ivan.cukic@yandex.com>
Date: Mon, 26 May 2014 00:17:05 +0200
Raw View
> > There is a dead thread that Vicente Escriba started some time ago:
> > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f
> > 117Z5yZkJ
> Yes this Vicente is me.
I noticed only after sending the email :)
> - Would this mean that we have to add the map/bins/cacth_error/unit as
> member functions and that the default forwards to members functions?
Yes. Definitely not pretty, but since it already is the practice.
> - non-member functions don't chain as well as member functions.
I agree, being accustomed to dot-notation. But, I guess a lot of
functional developers would beg to differ.
> - we will need infix operators
Lets hope the proposal for D's UFCS (can't recall the proposal id number) will
get a green light.
Otherwise, we'll probably need something like boost.range adaptors.
Cheerio,
Ivan
p.s. I apologize if this mail comes in two copies, seems like gmail and google
groups filter out gmx.com mail addresses. Switched to another provider.
--
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76
--
---
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: Ivan =?utf-8?B?xIx1a2nEhw==?= <ivan.cukic@gmx.com>
Date: Sun, 25 May 2014 23:34:41 +0200
Raw View
> > There is a dead thread that Vicente Escriba started some time ago:
> > https://groups.google.com/a/isocpp.org/d/msg/std-proposals/KCqwEq49GMA/a5f
> > 117Z5yZkJ
> Yes this Vicente is me.
I noticed only after sending the email :)
> - Would this mean that we have to add the map/bins/cacth_error/unit as
> member functions and that the default forwards to members functions?
Yes. Definitely not pretty, but since it already is the practice.
> - non-member functions don't chain as well as member functions.
Well, I agree, being accustomed to dot-notation. But, I guess a lot of
functional developers would beg to differ.
> - we will need infix operators
Lets hope the proposal for D's UFCS (can't recall the proposal id number) will
get a green light.
Otherwise, we'll probably need something like boost.range adaptors.
Cheerio,
Ivan
--
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76
--
---
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: Pierre Talbot <ptalbot@hyc.io>
Date: Tue, 27 May 2014 23:04:50 +0200
Raw View
Hi Ivan,
First of all, thank you for the feedback.
> Exchanging the types would also allow to specify the default value of
> E to be std::exception_ptr.
std::exception_ptr being the default type for E might not be a good
idea. Exceptions are a way to handle error but expected is another. The
only relation between both is that expected provides support to interact
from and to an existing system or interface living in the exception
world. For example, error_condition or error_code could often be a
better choice. Furthermore, I'd not encourage the use of exception where
they are not required, setting E to std::exception_ptr certainly
encourage this.
> I'd rather that the api caters to the "happy path" (to quote E.
> Meijer) than to the failure cases.
This is true, however in practice I suspect that users will use a type
definition on expected with their own error type:
template <class T>
using expectation = expected<error_condition, T>;
We get back our "happy path" :-)
> As for fmap, this will start the non-generic way of naming. futures
> have .then, this will have .fmap (and .then?), who knows how the next
> monad will name its bind operator. (IMO, this should be a part of
> another proposal, along with the all the stuff that require new
> core-language things like <-, and catch_exception {})
IMHO, we didn't use fancy names neither we invented any :-) map and bind
directly comes from the category theory and Haskell. In Haskell, they
named the 'map' operation 'fmap' because 'map' was already used for list
and they didn't want to break anything. We don't have this requirement
in C++ for the member function. 'bind' comes from the monads and 'then'
comes from the future interface. We provide the three methods since they
have a different signature (see section 5.9 in the proposal).
> I agree, being accustomed to dot-notation. But, I guess a lot of
> functional developers would beg to differ.
Note that we add a syntax for a do-notation like in the section 7.1.
Cheers,
Pierre
--
---
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: Ivan =?utf-8?B?xIx1a2nEhw==?= <ivan.cukic@yandex.com>
Date: Wed, 28 May 2014 23:10:06 +0200
Raw View
Hi Pierre,
> First of all, thank you for the feedback.
Thank you for the proposal - I'd love to see a few more functional parts like
this in STL.
> std::exception_ptr being the default type for E might not be a good
> idea. Exceptions are a way to handle error but expected is another. The
Well, integer error codes vs typed errors... I guess we could start a holy war
over this :)
> This is true, however in practice I suspect that users will use a type
> definition on expected with their own error type:
>
> template <class T>
> using expectation = expected<error_condition, T>;
>
> We get back our "happy path" :-)
Yes, I guess that will become a new common idiom. Honestly, I'm not overly
happy about STL things needing a typedef/using to make them useful, but yes,
this would be ok.
> IMHO, we didn't use fancy names neither we invented any :-) map and bind
I agree map/fmap/bind are already established names, but outside of C++. This
remark was not aimed for this proposal per se, but more of a general worry
that we started introducing monads into C++ without predefining the common
terminology.
> Note that we add a syntax for a do-notation like in the section 7.1.
Yes, saw that. That is one of the things I'd put in a separate proposal - I'm
guessing it will receive more resistance than just the expected<...> template.
Cheerio,
Ivan
KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Pierre Talbot <ptalbot@hyc.io>
Date: Thu, 29 May 2014 20:08:40 +0200
Raw View
On 05/28/2014 11:10 PM, Ivan =C4=8Cuki=C4=87 wrote:
> Hi Pierre,
>
>> First of all, thank you for the feedback.
> Thank you for the proposal - I'd love to see a few more functional parts =
like
> this in STL.
>
>> std::exception_ptr being the default type for E might not be a good
>> idea. Exceptions are a way to handle error but expected is another. The
> Well, integer error codes vs typed errors... I guess we could start a hol=
y war
> over this :)
IMHO, typed errors are only useful when there is contextual information=20
to report along with the error. Otherwise integer error codes do the job=20
well.
Exception are only a kind of "typed error" and I'd advise to use a=20
custom error structure (with virtual methods) over exceptions since we=20
cannot add virtual method to the existing std::exception type. Another=20
possibility would be to use a variant<E1, E2, ...> but it has the=20
inconvenient to change the signature if a new error is added.
Using exceptions when we don't need to interface with code using=20
exception is bad, it means we use the try-catch mechanism to go through=20
a hierarchy, this is not the goal of try-catch.
>
>> This is true, however in practice I suspect that users will use a type
>> definition on expected with their own error type:
>>
>> template <class T>
>> using expectation =3D expected<error_condition, T>;
>>
>> We get back our "happy path" :-)
> Yes, I guess that will become a new common idiom. Honestly, I'm not overl=
y
> happy about STL things needing a typedef/using to make them useful, but y=
es,
> this would be ok.
>
>> IMHO, we didn't use fancy names neither we invented any :-) map and bind
> I agree map/fmap/bind are already established names, but outside of C++. =
This
> remark was not aimed for this proposal per se, but more of a general worr=
y
> that we started introducing monads into C++ without predefining the commo=
n
> terminology.
>
>> Note that we add a syntax for a do-notation like in the section 7.1.
> Yes, saw that. That is one of the things I'd put in a separate proposal -=
I'm
> guessing it will receive more resistance than just the expected<...> temp=
late.
I'm totally agree with you, this has little to do in the expected=20
proposal. We put it in because we wanted people to see aesthetic ways of=20
manipulating expected and monads in general.
Cheers,
Pierre
--=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: Ivan =?utf-8?B?xIx1a2nEhw==?= <ivan@mi.sanu.ac.rs>
Date: Thu, 05 Jun 2014 10:09:24 +0200
Raw View
> IMHO, typed errors are only useful when there is contextual information
> to report along with the error. Otherwise integer error codes do the job
> well.
As I said, it could start a war.
One might argue that if you don't need contextual information, you don't need
any contextual information - the error id, and that using only std::optional
would suffice.
> Exception are only a kind of "typed error" and I'd advise to use a
> custom error structure (with virtual methods) over exceptions since we
I agree.
> > Yes, saw that. That is one of the things I'd put in a separate proposal -
> > I'm guessing it will receive more resistance than just the expected<...>
> > template.
> I'm totally agree with you, this has little to do in the expected
> proposal. We put it in because we wanted people to see aesthetic ways of
> manipulating expected and monads in general.
Superb. :)
Cheers,
Ivan
--
Money can't buy happiness, but neither can poverty.
-- Leo Rosten
--
---
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: Pierre Talbot <ptalbot@hyc.io>
Date: Thu, 05 Jun 2014 11:14:05 +0200
Raw View
Le 05/06/2014 10:09, Ivan =C4=8Cuki=C4=87 a =C3=A9crit :
>> IMHO, typed errors are only useful when there is contextual information
>> to report along with the error. Otherwise integer error codes do the job
>> well.
> As I said, it could start a war.
>
> One might argue that if you don't need contextual information, you don't =
need
> any contextual information - the error id, and that using only std::optio=
nal
> would suffice.
It doesn't look like a war to me, we're just trying to categorize the=20
usages of error reporting :-)
So indeed, the error id is a *static* contextual information, so=20
*dynamic* contextual information would include runtime information. BTW,=20
this is something we could add in the introduction of the proposal.
Thanks for comments,
Pierre
--=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: tomaszkam@gmail.com
Date: Fri, 6 Jun 2014 02:43:59 -0700 (PDT)
Raw View
------=_Part_178_31535809.1402047839664
Content-Type: text/plain; charset=UTF-8
The original class was defined just as you propose. We moved to the current
expected<E,T> form to be able to write
>
> auto e = expected<error_condition>::make(1) // result is
> expected<error_condition, int>
>
> Others have already do the same remark, and we would not have any problem
> rolling back to the original design. We will need a different type
> constructor expected_tc (a better name of course)
>
> auto e = expected_tc<error_condition>::make(1) // result is
> expected<error_condition, int
>
With the original class defintion expected<T,E> you can still achive very
simliar inteface, by declaring:
template<typename E = exception_ptr, T>
expected<T, E> make_expected(T); //This should use perfect forwarding and
decay for argument, but it is cleaner that way
Then you will be able to write:
auto a = make_expected(1); // result is
excepted<int>
auto b = make_expected<error_condition>(1);// result is expected<int,
error_condition>
--
---
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_178_31535809.1402047839664
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The original class was defined just as you propose. We mov=
ed to the
current expected<E,T> form to be able to write<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div>
<br>
auto e =3D expected<error_condition>::<wbr>make(1) // resul=
t is
expected<error_condition, int><br>
<br>
Others have already do the same remark, and we would not have any
problem rolling back to the original design. We will need a
different type constructor expected_tc (a better name of course)<br>
<br>
auto e =3D expected_tc<error_condition>::<wbr>make(1) // re=
sult is
expected<error_condition, int <br></div></blockquote><div>With the o=
riginal class defintion expected<T,E> you can still achive very simli=
ar inteface, by declaring:<br><br>template<typename E =3D exception_ptr,=
T><br>expected<T, E> make_expected(T); //This should use perfect =
forwarding and decay for argument, but it is cleaner that way<br><br>Then y=
ou will be able to write:<br>auto a =3D make_expected(1); &nb=
sp; // resul=
t is excepted<int><br>auto b =3D make_expected<error_condition>=
(1);// result is
expected<int, error_condition><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 />
------=_Part_178_31535809.1402047839664--
.