------=_Part_59_31696036.1400924812559
Content-Type: text/plain; charset=UTF-8

Hi,

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.

1.
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.

This is the other side of the same coin, for 'expected' I'd expect the
first argument to be the expected type.

Exchanging the types would also allow to specify the default value of E to
be std::exception_ptr.

template <typename T, typename E = std::exception_ptr>
class expected { ... };

Otherwise, people will rather opt in to use std::optional<T> because it is
easier to write, and does not pollute the code.

2.
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 {})

3.
Unexpect sounds strange :)


Cheerio,
Ivan



[1] https://hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-Error.html

--

---
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_59_31696036.1400924812559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<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 comm=
ents for the proposal.</div><div><br></div><div>1.</div><div>The main issue=
 I have with it is the order of &lt;E, T&gt;. 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>This is the other side of the same co=
in, 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 th=
e default value of E to be std::exception_ptr.</div><div><div><br></div><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pr=
ettyprint"><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"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</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: #008;" class=3D"styled-by-prettify">typename</span><spa=
n 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"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">exception_ptr</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-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-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code=
></div><div><br></div></div><div>Otherwise, people will rather opt in to us=
e std::optional&lt;T&gt; because it is easier to write, and does not pollut=
e the code.</div><div><br></div><div>2.</div><div>As for fmap, this will st=
art 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. (I=
MO, this should be a part of another proposal, along with the all the stuff=
 that require new core-language things like &lt;-, and catch_exception {})<=
/div><div><br></div><div>3.</div><div>Unexpect sounds strange :)</div><div>=
<br></div><div><br></div><div>Cheerio,</div><div>Ivan</div><div><br></div><=
div><br></div><div><br></div><div>[1]&nbsp;https://hackage.haskell.org/pack=
age/mtl-1.1.0.2/docs/Control-Monad-Error.html</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_59_31696036.1400924812559--

.