------=_Part_3872_1474138.1366793596465
Content-Type: text/plain; charset=ISO-8859-1

I've been looking at the latest proposal and I was kind of disappointed by
the overly pointer interface. This proposal seems to capture one small
aspect of Maybe/option types in functional languages then just completely
ignores the rest. std::optional has all the disadvantages of using pointer
return types and only has one advantage which is not needing heap
allocations.

Maybe/option types in functional language are written with algebraic
data-types and decomposed with pattern matching and case expressions, the
compiler does case-analysis to throw errors/warnings at compile-time when
you do not cover all the cases of an algebraic data-type. We do not have
these features in C++ and thus it is just as easy to accidentally miss out
the fail case with std::optional than it is with pointer types. It does not
help the matter that std::optional is being treated syntactically like a
pointer.

Where are all the typical higher-level functions I'd expect from a Maybe
type. There's barely any benefit of using std::optional except for the
interface of your functions as it makes it a tad more explicit that the
function is partial and can fail but the type-system has no knowledge of
that in any way.

--

---
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/?hl=en.



------=_Part_3872_1474138.1366793596465
Content-Type: text/html; charset=ISO-8859-1

I've been looking at the latest proposal and I was kind of disappointed
by the overly pointer interface. This proposal seems to capture one
small aspect of Maybe/option types in functional languages then just
completely ignores the rest. std::optional has all the disadvantages of
using pointer return types and only has one advantage which is not
needing heap allocations.<br><br>Maybe/option types in functional
language are written with algebraic data-types and decomposed with
pattern matching and case expressions, the compiler does case-analysis
to throw errors/warnings at compile-time when you do not cover all the
cases of an algebraic data-type. We do not have these features in C++
and thus it is just as easy to accidentally miss out the fail case with
std::optional than it is with pointer types. It does not help the matter
 that std::optional is being treated syntactically like a pointer.<br><br>Where
 are all the typical higher-level functions I'd expect from a Maybe
type. There's barely any benefit of using std::optional except for the
interface of your functions as it makes it a tad more explicit that the function is partial and can
fail but the type-system has no knowledge of that in any way.<br>

<p></p>

-- <br />
&nbsp;<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 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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3872_1474138.1366793596465--

.

--047d7b2e088701329f04db17d188
Content-Type: text/plain; charset=ISO-8859-1

On 24 April 2013 11:53, snk_kid <korcan.hussein@googlemail.com> wrote:

> I've been looking at the latest proposal and I was kind of disappointed by
> the overly pointer interface. This proposal seems to capture one small
> aspect of Maybe/option types in functional languages then just completely
> ignores the rest. std::optional has all


The proposal isn't trying to capture the aspects of maybe/option types in
functional languages.


> the disadvantages of using pointer return types and only has one advantage
> which is not needing heap allocations.
>

You misunderstand the advantage. Not needing heap allocations is a minor
advantage, but the major
advantage is having clear semantics of ownership. The combination of this
advantages makes
optional equivalent to smart pointers, but slightly superior.

Maybe/option types in functional language are written with algebraic
> data-types and decomposed with pattern matching and case expressions, the
> compiler does case-analysis to throw errors/warnings at compile-time when
> you do not cover all the cases of an algebraic data-type. We do not have
> these features in C++ and thus it is just as easy to accidentally miss out
> the fail case with std::optional than it is with pointer types. It does not
> help the matter that std::optional is being treated syntactically like a
> pointer.
>

I fail to see an actual problem there.


Where are all the typical higher-level functions I'd expect from a Maybe
> type. There's barely any benefit of using std::optional except for the
> interface of your functions as it makes it a tad more explicit that the
> function is partial and can fail but the type-system has no knowledge of
> that in any way.
>
>
>
I can't know what higher-level functions you expect, so perhaps you could
give some examples?

--

---
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/?hl=en.



--047d7b2e088701329f04db17d188
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 24 April 2013 11:53, snk_kid <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.hussein@google=
mail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;ve been looking at the latest proposal=
 and I was kind of disappointed=20
by the overly pointer interface. This proposal seems to capture one=20
small aspect of Maybe/option types in functional languages then just=20
completely ignores the rest. std::optional has all </blockquote><div><br></=
div><div>The proposal isn&#39;t trying to capture the aspects of maybe/opti=
on types in functional languages.<br>=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
the disadvantages of=20
using pointer return types and only has one advantage which is not=20
needing heap allocations.<br></blockquote><div><br></div><div>You misunders=
tand the advantage. Not needing heap allocations is a minor advantage, but =
the major<br>advantage is having clear semantics of ownership. The combinat=
ion of this advantages makes<br>
</div><div>optional equivalent to smart pointers, but slightly superior.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Maybe/option types in functional=
=20
language are written with algebraic data-types and decomposed with=20
pattern matching and case expressions, the compiler does case-analysis=20
to throw errors/warnings at compile-time when you do not cover all the=20
cases of an algebraic data-type. We do not have these features in C++=20
and thus it is just as easy to accidentally miss out the fail case with=20
std::optional than it is with pointer types. It does not help the matter
 that std::optional is being treated syntactically like a pointer.<br></blo=
ckquote><div><br></div><div>I fail to see an actual problem there.=A0 <br><=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
Where
 are all the typical higher-level functions I&#39;d expect from a Maybe=20
type. There&#39;s barely any benefit of using std::optional except for the=
=20
interface of your functions as it makes it a tad more explicit that the fun=
ction is partial and can=20
fail but the type-system has no knowledge of that in any way.<span class=3D=
"HOEnZb"><font color=3D"#888888"><br>

<p></p>

<br></font></span></blockquote><div><br></div><div>I can&#39;t know what hi=
gher-level functions you expect, so perhaps you could give some examples? <=
br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b2e088701329f04db17d188--

.

------=_Part_3124_33410284.1366805017868
Content-Type: text/plain; charset=ISO-8859-1

(Since my original reply seems to have gone MIA thanks to me directly
replying to Ville, here's a copy-paste...)

The proposal isn't trying to capture the aspects of maybe/option types in
> functional languages.
>

I'm a tad bit sad that it's not even trying to bring us the power of those
types.

>
I can't know what higher-level functions you expect, so perhaps you could
> give some examples?
>

Mapping and monadic binding come to mind, which allow safe and easy access,
while keeping the semantics of the Maybe type in mind.

A pseudo-example for std::optional:

int mul(int i){ return i * 2; }

std::optional<int> maybe_mul(int i){
  if(i < 10) return i * 2;
  return std::nullopt;
}

std::optional<int> x(std::nullopt);

// calls `mul` with value if it has one and wraps the returned value
// in an optional<int>, otherwise returns std::nullopt
auto y = x.fmap(mul);

// almost like `fmap`, but unwraps nested optionals
// i.e. std::optional<std::optional<int>> -> std::optional<int>
auto z = x.bind(maybe_mul);

--

---
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/?hl=en.



------=_Part_3124_33410284.1366805017868
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

(Since my original reply seems to have gone MIA thanks to me directly reply=
ing to Ville, here's a copy-paste...)<br><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">The proposal isn't trying t=
o capture the aspects of maybe/option types in functional languages.</div><=
/blockquote><div><br>I'm a tad bit sad that it's not even trying to bring u=
s the power of those types.</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
<div class=3D"im"><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v>I can't know what higher-level functions you expect, so perhaps you could=
 give some examples? <br>
</div></blockquote></div><br>Mapping and monadic binding come to=20
mind, which allow safe and easy access, while keeping the semantics of=20
the Maybe type in mind.<br><br>A pseudo-example for std::optional:<br><br><=
div 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><div><span style=3D"color:#008">int</span><span style=3D""> mul</span=
><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><s=
pan style=3D""> i</span><span style=3D"color:#660">){</span><span style=3D"=
"> </span><span style=3D"color:#008">return</span><span style=3D""> i </spa=
n><span style=3D"color:#660">*</span><span style=3D""> </span><span style=
=3D"color:#066">2</span><span style=3D"color:#660">;</span><span style=3D""=
> </span><span style=3D"color:#660">}</span><span style=3D""><br>
<br>std</span><span style=3D"color:#660">::</span><span style=3D"">optional=
</span><span style=3D"color:#080">&lt;int&gt;</span><span style=3D""> maybe=
_mul</span><span style=3D"color:#660">(</span><span style=3D"color:#008">in=
t</span><span style=3D""> i</span><span style=3D"color:#660">){</span><span=
 style=3D""><br>
&nbsp; </span><span style=3D"color:#008">if</span><span style=3D"color:#660=
">(</span><span style=3D"">i </span><span style=3D"color:#660">&lt;</span><=
span style=3D""> </span><span style=3D"color:#066">10</span><span style=3D"=
color:#660">)</span><span style=3D""> </span><span style=3D"color:#008">ret=
urn</span><span style=3D""> i </span><span style=3D"color:#660">*</span><sp=
an style=3D""> </span><span style=3D"color:#066">2</span><span style=3D"col=
or:#660">;</span><span style=3D""><br>
&nbsp; </span><span style=3D"color:#008">return</span><span style=3D""> std=
</span><span style=3D"color:#660">::</span><span style=3D"">nullopt</span><=
span style=3D"color:#660">;</span><span style=3D""><br></span><span style=
=3D"color:#660">}</span><span style=3D""><br>
<br>std</span><span style=3D"color:#660">::</span><span style=3D"">optional=
</span><span style=3D"color:#080">&lt;int&gt;</span><span style=3D""> x</sp=
an><span style=3D"color:#660">(</span><span style=3D"">std</span><span styl=
e=3D"color:#660">::</span><span style=3D"">nullopt</span><span style=3D"col=
or:#660">);</span><span style=3D""><br>
</span><br><code><span style=3D""> </span><span style=3D"color:#800">// cal=
ls `mul` with value if it has one and wraps the returned value</span><span =
style=3D""></span></code><br><code><span style=3D"color:#800">// in an opti=
onal&lt;int&gt;, otherwise returns std::nullopt</span><span style=3D""><br>
</span></code><span style=3D"color:#008">auto</span><span style=3D""> y </s=
pan><span style=3D"color:#660">=3D</span><span style=3D""> x</span><span st=
yle=3D"color:#660">.</span><span style=3D"">fmap</span><span style=3D"color=
:#660">(</span><span style=3D"">mul</span><span style=3D"color:#660">);</sp=
an><span style=3D""><br>
</span><span style=3D""><br>// almost like `fmap`, but unwraps nested optio=
nals<br>// i.e. std::optional&lt;std::optional&lt;int&gt;&gt; -&gt; std::op=
tional&lt;int&gt;<br></span><span style=3D"color:#008">auto</span><span sty=
le=3D""> z </span><span style=3D"color:#660">=3D</span><span style=3D""> x<=
/span><span style=3D"color:#660">.</span><span style=3D"">bind</span><span =
style=3D"color:#660">(</span><span style=3D"">maybe_mul</span><span style=
=3D"color:#660">);</span><span style=3D""><br>
</span></div></code></div><br>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3124_33410284.1366805017868--

.

------=_Part_137_976083.1366805571456
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, April 24, 2013 1:03:37 PM UTC+1, Xeo wrote:
>
> (Since my original reply seems to have gone MIA thanks to me directly
> replying to Ville, here's a copy-paste...)
>
> The proposal isn't trying to capture the aspects of maybe/option types in
>> functional languages.
>>
>
> I'm a tad bit sad that it's not even trying to bring us the power of those
> types.
>
>>
> I can't know what higher-level functions you expect, so perhaps you could
>> give some examples?
>>
>
> Mapping and monadic binding come to mind, which allow safe and easy
> access, while keeping the semantics of the Maybe type in mind.
>
> A pseudo-example for std::optional:
>
> int mul(int i){ return i * 2; }
>
> std::optional<int> maybe_mul(int i){
>   if(i < 10) return i * 2;
>   return std::nullopt;
> }
>
> std::optional<int> x(std::nullopt);
>
> // calls `mul` with value if it has one and wraps the returned value
> // in an optional<int>, otherwise returns std::nullopt
> auto y = x.fmap(mul);
>
> // almost like `fmap`, but unwraps nested optionals
> // i.e. std::optional<std::optional<int>> -> std::optional<int>
> auto z = x.bind(maybe_mul);
>
>
Is it necessary for those to be member functions?

The C++ standard library still has no convenient way to split a string into
tokens, does that mean C++98 shouldn't have included std::string?  Or does
it just mean you might have to use something not in namespace std?


--

---
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/?hl=en.



------=_Part_137_976083.1366805571456
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, April 24, 2013 1:03:37 PM UTC+1, Xeo wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">(Since my original reply seems to have g=
one MIA thanks to me directly replying to Ville, here's a copy-paste...)<br=
><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">The proposal isn't trying t=
o capture the aspects of maybe/option types in functional languages.</div><=
/blockquote><div><br>I'm a tad bit sad that it's not even trying to bring u=
s the power of those types.</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
<div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div>I can't kno=
w what higher-level functions you expect, so perhaps you could give some ex=
amples? <br>
</div></blockquote></div><br>Mapping and monadic binding come to=20
mind, which allow safe and easy access, while keeping the semantics of=20
the Maybe type in mind.<br><br>A pseudo-example for std::optional:<br><br><=
div 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><div><span style=3D"color:#008">int</span><span> mul</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#008">int</span><span> i</spa=
n><span style=3D"color:#660">){</span><span> </span><span style=3D"color:#0=
08">return</span><span> i </span><span style=3D"color:#660">*</span><span> =
</span><span style=3D"color:#066">2</span><span style=3D"color:#660">;</spa=
n><span> </span><span style=3D"color:#660">}</span><span><br>
<br>std</span><span style=3D"color:#660">::</span><span>optional</span><spa=
n style=3D"color:#080">&lt;int&gt;</span><span> maybe_mul</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">int</span><span> i</span=
><span style=3D"color:#660">){</span><span><br>
&nbsp; </span><span style=3D"color:#008">if</span><span style=3D"color:#660=
">(</span><span>i </span><span style=3D"color:#660">&lt;</span><span> </spa=
n><span style=3D"color:#066">10</span><span style=3D"color:#660">)</span><s=
pan> </span><span style=3D"color:#008">return</span><span> i </span><span s=
tyle=3D"color:#660">*</span><span> </span><span style=3D"color:#066">2</spa=
n><span style=3D"color:#660">;</span><span><br>
&nbsp; </span><span style=3D"color:#008">return</span><span> std</span><spa=
n style=3D"color:#660">::</span><span>nullopt</span><span style=3D"color:#6=
60">;</span><span><br></span><span style=3D"color:#660">}</span><span><br>
<br>std</span><span style=3D"color:#660">::</span><span>optional</span><spa=
n style=3D"color:#080">&lt;int&gt;</span><span> x</span><span style=3D"colo=
r:#660">(</span><span>std</span><span style=3D"color:#660">::</span><span>n=
ullopt</span><span style=3D"color:#660">);</span><span><br>
</span><br><code><span> </span><span style=3D"color:#800">// calls `mul` wi=
th value if it has one and wraps the returned value</span><span></span></co=
de><br><code><span style=3D"color:#800">// in an optional&lt;int&gt;, other=
wise returns std::nullopt</span><span><br>
</span></code><span style=3D"color:#008">auto</span><span> y </span><span s=
tyle=3D"color:#660">=3D</span><span> x</span><span style=3D"color:#660">.</=
span><span>fmap</span><span style=3D"color:#660">(</span><span>mul</span><s=
pan style=3D"color:#660">);</span><span><br>
</span><span><br>// almost like `fmap`, but unwraps nested optionals<br>// =
i.e. std::optional&lt;std::optional&lt;<wbr>int&gt;&gt; -&gt; std::optional=
&lt;int&gt;<br></span><span style=3D"color:#008">auto</span><span> z </span=
><span style=3D"color:#660">=3D</span><span> x</span><span style=3D"color:#=
660">.</span><span>bind</span><span style=3D"color:#660">(</span><span>mayb=
e_mul</span><span style=3D"color:#660">);</span><span><br>
</span></div></code></div><br></blockquote><div><br>Is it necessary for tho=
se to be member functions?<br><br>The C++ standard library still has no con=
venient way to split a string into tokens, does that mean C++98 shouldn't h=
ave included std::string?&nbsp; Or does it just mean you might have to use =
something not in namespace std?<br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_137_976083.1366805571456--

.

------=_Part_4032_15009563.1366806277157
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, April 24, 2013 2:12:51 PM UTC+2, Jonathan Wakely wrote:
>
>
> Is it necessary for those to be member functions?
>
>
No, of course not - that was just an example, since the bind in Haskell is
an infix operator (>>=) so it would've been `x >>= maybe_mul`. I just
wanted to keep that.

But actually, there's another problem, which I mention and address in my
paper<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lxzvnnNSpnE/vL3YgPpR9nsJ>- currently, it's not really *feasible* to provide such interfaces because
passing overloaded / templated / default-argumented functions to a function
template is a huge PITA.

But back to those interfaces: I just feel like people will adopt unsafe
access patterns for std::optional without them. But maybe I'm just rambling
because I miss Maybe in C++... :)

--

---
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/?hl=en.



------=_Part_4032_15009563.1366806277157
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, April 24, 2013 2:12:51 PM UTC+2, Jonathan Wakely wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><br><div>Is it necessary for those t=
o be member functions?<br><br></div></blockquote><div><br>No, of course not=
 - that was just an example, since the bind in Haskell is an infix operator=
 (&gt;&gt;=3D) so it would've been `x &gt;&gt;=3D maybe_mul`. I just wanted=
 to keep that.<br><br>But actually, there's another problem, which I mentio=
n and address in <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/st=
d-proposals/lxzvnnNSpnE/vL3YgPpR9nsJ">my paper</a> - currently, it's not re=
ally *feasible* to provide such interfaces because passing overloaded / tem=
plated / default-argumented functions to a function template is a huge PITA=
..<br><br>But back to those interfaces: I just feel like people will adopt u=
nsafe access patterns for std::optional without them. But maybe I'm just ra=
mbling because I miss Maybe in C++... :)<br></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_4032_15009563.1366806277157--

.

--089e0118279cb5e6e804db1a760f
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 24, 2013 at 5:53 AM, snk_kid <korcan.hussein@googlemail.com>wrote:

> I've been looking at the latest proposal and I was kind of disappointed by
> the overly pointer interface.


Why?


> This proposal seems to capture one small aspect of Maybe/option types in
> functional languages then just completely ignores the rest.


What is the rest that it completely ignore *that is specific to Maybe and
not just every algebraic type*


> std::optional has all the disadvantages of using pointer return types


There is no such thing as a pointer return type. Please rephrase so we can
understand what you mean.


> and only has one advantage which is not needing heap allocations.
>
> What other advantages do you think it should have?


> Maybe/option types in functional language are written with algebraic
> data-types and decomposed with pattern matching and case expressions, the
> compiler does case-analysis to throw errors/warnings at compile-time when
> you do not cover all the cases of an algebraic data-type. We do not have
> these features in C++ and thus it is just as easy to accidentally miss out
> the fail case with std::optional than it is with pointer types.


Correct.
However, even you are noticing that this is a consquence of C++ not being a
fully functional language, so, how is this the fault of the proposal (as
opposed to C++)??


> It does not help the matter that std::optional is being treated
> syntactically like a pointer.
>
> Yet, being trated like that helps to fulfill it's purpose. Have in mind
that there are no pointers in functional languages, so it would be a
mistake to try to model std::optional (or anything else in C++)  as you
would in, say, Haskell. A C++ utility must follow C++ common practices, not
those of functional languages.

Where are all the typical higher-level functions I'd expect from a Maybe
> type.


Mostly, they aren't anywhere yet, but notice that those do not belong to
Maybe *itself* but to algebraic types in general.

What you suggest is kind of correct but you are barking up the wrong tree.
We don't really want to add that to optional, for we have pair, tuple,
variant (eventually) and even any as well, all algebraic types. So what we
need is the "typical hgher-level functions" available to C++ types at
large, not just optional.

>
> There's barely any benefit of using std::optional except for the interface
> of your functions as it makes it a tad more explicit that the function is
> partial and can fail but the type-system has no knowledge of that in any
> way.
>

That is so wrong and limited that I won't even bother to argue back.

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.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/?hl=en.



--089e0118279cb5e6e804db1a760f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 24, 2013 at 5:53 AM, snk_kid <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:korcan.hussein@googlemail.com" target=3D"_blank">korcan.hussein@googlemai=
l.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;ve been looking at the latest proposal=
 and I was kind of disappointed=20
by the overly pointer interface.</blockquote><div><br></div><div>Why? <br><=
/div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"> This proposal seems to c=
apture one=20
small aspect of Maybe/option types in functional languages then just=20
completely ignores the rest. </blockquote><div><br></div><div>What is the r=
est that it completely ignore *that is specific to Maybe and not just every=
 algebraic type*<br></div><div>=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

std::optional has all the disadvantages of=20
using pointer return types </blockquote><div><br></div><div>There is no suc=
h thing as a pointer return type. Please rephrase so we can understand what=
 you mean.<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

and only has one advantage which is not=20
needing heap allocations.<br><br></blockquote><div>What other advantages do=
 you think it should have?<br></div><div>=A0<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">

Maybe/option types in functional=20
language are written with algebraic data-types and decomposed with=20
pattern matching and case expressions, the compiler does case-analysis=20
to throw errors/warnings at compile-time when you do not cover all the=20
cases of an algebraic data-type. We do not have these features in C++=20
and thus it is just as easy to accidentally miss out the fail case with=20
std::optional than it is with pointer types.</blockquote><div><br></div><di=
v>Correct.<br></div><div>However, even you are noticing that this is a cons=
quence of C++ not being a fully functional language, so, how is this the fa=
ult of the proposal (as opposed to C++)??<br>

</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">It does not help the mat=
ter
 that std::optional is being treated syntactically like a pointer.<br><br><=
/blockquote><div>Yet, being trated like that helps to fulfill it&#39;s purp=
ose. Have in mind that there are no pointers in functional languages, so it=
 would be a mistake to try to model std::optional (or anything else in C++)=
=A0 as you would in, say, Haskell. A C++ utility must follow C++ common pra=
ctices, not those of functional languages.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Where
 are all the typical higher-level functions I&#39;d expect from a Maybe=20
type.</blockquote><div><br></div><div>Mostly, they aren&#39;t anywhere yet,=
 but notice that those do not belong to Maybe *itself* but to algebraic typ=
es in general.<br><br></div><div>What you suggest is kind of correct but yo=
u are barking up the wrong tree. We don&#39;t really want to add that to op=
tional, for we have pair, tuple, variant (eventually) and even any as well,=
 all algebraic types. So what we need is the &quot;typical hgher-level func=
tions&quot; available to C++ types at large, not just optional.<br>

</div>=A0<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"> There&#39;s barely any benefit of =
using std::optional except for the=20
interface of your functions as it makes it a tad more explicit that the fun=
ction is partial and can=20
fail but the type-system has no knowledge of that in any way.<span class=3D=
"HOEnZb"><font color=3D"#888888"><br></font></span></blockquote><div><br></=
div><div>That is so wrong and limited that I won&#39;t even bother to argue=
 back. <br clear=3D"all">

</div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founder<br>=
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0118279cb5e6e804db1a760f--

.

--047d7b3441686c7da104db1a9102
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 24, 2013 at 9:24 AM, Xeo <hivemaster@hotmail.de> wrote:

> On Wednesday, April 24, 2013 2:12:51 PM UTC+2, Jonathan Wakely wrote:
>>
>>
>> Is it necessary for those to be member functions?
>>
>>
> No, of course not - that was just an example, since the bind in Haskell is
> an infix operator (>>=) so it would've been `x >>= maybe_mul`. I just
> wanted to keep that.
>
> But actually, there's another problem, which I mention and address in my
> paper<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lxzvnnNSpnE/vL3YgPpR9nsJ>- currently, it's not really *feasible* to provide such interfaces because
> passing overloaded / templated / default-argumented functions to a function
> template is a huge PITA.
>
> But back to those interfaces: I just feel like people will adopt unsafe
> access patterns for std::optional without them. But maybe I'm just rambling
> because I miss Maybe in C++... :)
>

I dare to say that you miss high level pattern matching in C++ (we have
templates but that's just a bit of it)

Like I responded to the first post, we really want something that works
with all algebraic types, not just std::optional.

FWIW, some of this has been discussed prior to the preparation of the final
proposal and we concluded that indeed, we better come up with something
really general and scalable. Hashkell's Maybe is so nice not just because
of maybe, whose definition is a couple of lines long, it's because of the
type system that it sits on top.

As for people adopting unsafe access patterns, keep in mind that this
utility standarized a large, 10-year-old existing practice: Boost.Optional.
So I don't see any reason for fearing that.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.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/?hl=en.



--047d7b3441686c7da104db1a9102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 24, 2013 at 9:24 AM, Xeo <span dir=3D"ltr">&lt;<a href=3D"mailto:hi=
vemaster@hotmail.de" target=3D"_blank">hivemaster@hotmail.de</a>&gt;</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 class=3D"im">On Wednesday, April 24, 20=
13 2:12:51 PM UTC+2, Jonathan Wakely wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<br><div>Is it necessary for those to be member functions?<br><br></div></b=
lockquote></div><div><br>No, of course not - that was just an example, sinc=
e the bind in Haskell is an infix operator (&gt;&gt;=3D) so it would&#39;ve=
 been `x &gt;&gt;=3D maybe_mul`. I just wanted to keep that.<br>

<br>But actually, there&#39;s another problem, which I mention and address =
in <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lx=
zvnnNSpnE/vL3YgPpR9nsJ" target=3D"_blank">my paper</a> - currently, it&#39;=
s not really *feasible* to provide such interfaces because passing overload=
ed / templated / default-argumented functions to a function template is a h=
uge PITA.<br>

<br>But back to those interfaces: I just feel like people will adopt unsafe=
 access patterns for std::optional without them. But maybe I&#39;m just ram=
bling because I miss Maybe in C++... :)<br></div></blockquote><div><br>

</div><div>I dare to say that you miss high level pattern matching in C++ (=
we have templates but that&#39;s just a bit of it)<br><br></div><div class=
=3D"h5">Like I responded to the first post, we really want something that w=
orks with all algebraic types, not just std::optional.<br>

<br>FWIW, some of this has been discussed prior to the preparation of the f=
inal proposal and we concluded that indeed, we better come up with somethin=
g really general and scalable. Hashkell&#39;s Maybe is so nice not just bec=
ause of maybe, whose definition is a couple of lines long, it&#39;s because=
 of the type system that it sits on top.<br>

</div><br></div><div class=3D"gmail_quote">As for people adopting unsafe ac=
cess patterns, keep in mind that this utility standarized a large, 10-year-=
old existing practice: Boost.Optional. So I don&#39;t see any reason for fe=
aring that.<br>

<br></div>Best<br></div><div class=3D"gmail_extra"><br>-- <br>Fernando Cacc=
iola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consul=
ting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3441686c7da104db1a9102--

.

------=_Part_15_100189.1366808506395
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, April 24, 2013 2:37:02 PM UTC+2, Fernando Cacciola wrote:
>
> I dare to say that you miss high level pattern matching in C++ (we have
> templates but that's just a bit of it)
>

Maybe (pun not intended), but I think true pattern matching would be hard
in C++. It kinda implies a revamp of the type-system.


> Like I responded to the first post, we really want something that works
> with all algebraic types, not just std::optional.
>

I guess. It's just that std::optional is now adopted, so it makes an easy
target. :)

--

---
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/?hl=en.



------=_Part_15_100189.1366808506395
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, April 24, 2013 2:37:02 PM UTC+2, Fernando Cacciola wrote:<blo=
ckquote 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>I dare to say that you miss high level pattern matchi=
ng in C++ (we have templates but that's just a bit of it)<br></div></div></=
div></div></blockquote><div><br>Maybe (pun not intended), but I think true =
pattern matching would be hard in C++. It kinda implies a revamp of the typ=
e-system.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Like I responded to th=
e first post, we really want something that works with all algebraic types,=
 not just std::optional.<br></div></div></div></div></blockquote><div><br>I=
 guess. It's just that std::optional is now adopted, so it makes an easy ta=
rget. :)<br></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_15_100189.1366808506395--

.

--089e0149405c951aa604db1b014b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 24, 2013 at 10:01 AM, Xeo <hivemaster@hotmail.de> wrote:

> On Wednesday, April 24, 2013 2:37:02 PM UTC+2, Fernando Cacciola wrote:
>>
>> I dare to say that you miss high level pattern matching in C++ (we have
>> templates but that's just a bit of it)
>>
>
> Maybe (pun not intended), but I think true pattern matching would be hard
> in C++. It kinda implies a revamp of the type-system.
>
>
Of course. Languages such as Fenix emerged as "clean way" to do that to C++

OTOH,

> Like I responded to the first post, we really want something that works
>> with all algebraic types, not just std::optional.
>>
>
> I guess. It's just that std::optional is now adopted, so it makes an easy
> target. :)
>

Fair enough.

Have you known FC++? That was one hell of a work, and got it quite right
IMO, given the C++ of the time.


Best



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.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/?hl=en.



--089e0149405c951aa604db1b014b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Apr 24, 2013 at 10:01 AM, Xeo <span dir=3D"ltr">&lt;<a href=3D"mailto:h=
ivemaster@hotmail.de" target=3D"_blank">hivemaster@hotmail.de</a>&gt;</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 class=3D"im">On Wednesday, April 24, 20=
13 2:37:02 PM UTC+2, Fernando Cacciola wrote:<blockquote class=3D"gmail_quo=
te" 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>I dare to say that yo=
u miss high level pattern matching in C++ (we have templates but that&#39;s=
 just a bit of it)<br></div></div></div></div></blockquote></div><div><br>
Maybe (pun not intended), but I think true pattern matching would be hard i=
n C++. It kinda implies a revamp of the type-system.<br>
=A0<br></div></blockquote><div>Of course. Languages such as Fenix emerged a=
s &quot;clean way&quot; to do that to C++<br><br></div><div>OTOH,=A0 <br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">

<div></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>Like I responded to the fir=
st post, we really want something that works with all algebraic types, not =
just std::optional.<br>

</div></div></div></div></blockquote></div><div><br>I guess. It&#39;s just =
that std::optional is now adopted, so it makes an easy target. :)<br></div>=
</blockquote><div><br></div><div>Fair enough.<br><br></div><div>Have you kn=
own FC++? That was one hell of a work, and got it quite right IMO, given th=
e C++ of the time.<br>

<br><br></div><div>Best</div></div><br><br clear=3D"all"><br>-- <br>Fernand=
o Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-=
consulting.com">http://www.scisoft-consulting.com</a>
</div></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e0149405c951aa604db1b014b--

.

--047d7b34382c6cf91804db20b0d7
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 24, 2013 at 8:03 AM, Xeo <hivemaster@hotmail.de> wrote:

> (Since my original reply seems to have gone MIA thanks to me directly
> replying to Ville, here's a copy-paste...)
>
>
> The proposal isn't trying to capture the aspects of maybe/option types in
>> functional languages.
>>
>
> I'm a tad bit sad that it's not even trying to bring us the power of those
> types.
>
>>
> I can't know what higher-level functions you expect, so perhaps you could
>> give some examples?
>>
>
> Mapping and monadic binding come to mind, which allow safe and easy
> access, while keeping the semantics of the Maybe type in mind.
>
> A pseudo-example for std::optional:
>
> int mul(int i){ return i * 2; }
>
> std::optional<int> maybe_mul(int i){
>   if(i < 10) return i * 2;
>   return std::nullopt;
> }
>
> std::optional<int> x(std::nullopt);
>
> // calls `mul` with value if it has one and wraps the returned value
> // in an optional<int>, otherwise returns std::nullopt
> auto y = x.fmap(mul);
>
> // almost like `fmap`, but unwraps nested optionals
> // i.e. std::optional<std::optional<int>> -> std::optional<int>
> auto z = x.bind(maybe_mul);
>


I'm still trying to understand what you are asking for (since my Haskell
is, let's say "rusty" or "nonexistent").
Let's try it this way:

if you had a function int func(int) , would you like to somehow
*automatically* have the function optional<int> func(optional<int>)?

ie pass an optional<int> into func gives you the correct int result if the
optional<> is engaged, else gives you nullopt?

Furthermore, we could apply this to any function, of any types?

Foo someFunc(T1 t1, T2 t2, T3 t3);

pass in an empty optional<Tn> into any of these and you get back an empty
optional<Foo>?

Is that the request?

In C++, something like:

template <typename F> // F is a Function signature
optional<result_of<F>::type> apply(F f, optional<arg<F,0>::type> a1,
optional<arg<F,1>::type> a2, etc...)
{
   if (!a1 || !a2 || ...)
      return optional<result_of<F>::type>(); // empty

   return f(*a1, *a2, ...);
}

use:

string function(int x, double y);

optional<double> ymaybe = ...;

optional<string> res = apply(function, 12, ymaybe);

?

Not as pretty as in a functional language, but I suspect it is doable.

--

---
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/?hl=en.



--047d7b34382c6cf91804db20b0d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Apr 24, 2013 at 8:03 AM, Xeo <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hivemaster@hotmail.de" target=3D"_blank">hivemaster@hotmail.de</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">(Since my original reply seems to have gone =
MIA thanks to me directly replying to Ville, here&#39;s a copy-paste...)<di=
v class=3D"im">
<br><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">The proposal isn&#39;t tryi=
ng to capture the aspects of maybe/option types in functional languages.</d=
iv>
</blockquote></div><div><br>I&#39;m a tad bit sad that it&#39;s not even tr=
ying to bring us the power of those types.</div><div class=3D"im"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">

</blockquote>
<div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div>I can&#39;t=
 know what higher-level functions you expect, so perhaps you could give som=
e examples? <br>

</div></blockquote></div><br></div>Mapping and monadic binding come to=20
mind, which allow safe and easy access, while keeping the semantics of=20
the Maybe type in mind.<br><br>A pseudo-example for std::optional:<br><br><=
div 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><div><span style=3D"color:#008">int</span><span> mul</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#008">int</span><span> i</spa=
n><span style=3D"color:#660">){</span><span> </span><span style=3D"color:#0=
08">return</span><span> i </span><span style=3D"color:#660">*</span><span> =
</span><span style=3D"color:#066">2</span><span style=3D"color:#660">;</spa=
n><span> </span><span style=3D"color:#660">}</span><span><br>

<br>std</span><span style=3D"color:#660">::</span><span>optional</span><spa=
n style=3D"color:#080">&lt;int&gt;</span><span> maybe_mul</span><span style=
=3D"color:#660">(</span><span style=3D"color:#008">int</span><span> i</span=
><span style=3D"color:#660">){</span><span><br>

=A0 </span><span style=3D"color:#008">if</span><span style=3D"color:#660">(=
</span><span>i </span><span style=3D"color:#660">&lt;</span><span> </span><=
span style=3D"color:#066">10</span><span style=3D"color:#660">)</span><span=
> </span><span style=3D"color:#008">return</span><span> i </span><span styl=
e=3D"color:#660">*</span><span> </span><span style=3D"color:#066">2</span><=
span style=3D"color:#660">;</span><span><br>

=A0 </span><span style=3D"color:#008">return</span><span> std</span><span s=
tyle=3D"color:#660">::</span><span>nullopt</span><span style=3D"color:#660"=
>;</span><span><br></span><span style=3D"color:#660">}</span><span><br>
<br>std</span><span style=3D"color:#660">::</span><span>optional</span><spa=
n style=3D"color:#080">&lt;int&gt;</span><span> x</span><span style=3D"colo=
r:#660">(</span><span>std</span><span style=3D"color:#660">::</span><span>n=
ullopt</span><span style=3D"color:#660">);</span><span><br>

</span><br><code><span> </span><span style=3D"color:#800">// calls `mul` wi=
th value if it has one and wraps the returned value</span><span></span></co=
de><br><code><span style=3D"color:#800">// in an optional&lt;int&gt;, other=
wise returns std::nullopt</span><span><br>

</span></code><span style=3D"color:#008">auto</span><span> y </span><span s=
tyle=3D"color:#660">=3D</span><span> x</span><span style=3D"color:#660">.</=
span><span>fmap</span><span style=3D"color:#660">(</span><span>mul</span><s=
pan style=3D"color:#660">);</span><span><br>

</span><span><br>// almost like `fmap`, but unwraps nested optionals<br>// =
i.e. std::optional&lt;std::optional&lt;int&gt;&gt; -&gt; std::optional&lt;i=
nt&gt;<br></span><span style=3D"color:#008">auto</span><span> z </span><spa=
n style=3D"color:#660">=3D</span><span> x</span><span style=3D"color:#660">=
..</span><span>bind</span><span style=3D"color:#660">(</span><span>maybe_mul=
</span><span style=3D"color:#660">);</span><span><br>

</span></div></code></div><div class=3D"HOEnZb"><div class=3D"h5"></div></d=
iv></blockquote><div>=A0</div><div><br></div><div>I&#39;m still trying to u=
nderstand what you are asking for (since my Haskell is, let&#39;s say &quot=
;rusty&quot; or &quot;nonexistent&quot;).<br>
Let&#39;s try it this way:<br><br></div><div>if you had a function int func=
(int) , would you like to somehow *automatically* have the function optiona=
l&lt;int&gt; func(optional&lt;int&gt;)?<br><br></div><div>ie pass an option=
al&lt;int&gt; into func gives you the correct int result if the optional&lt=
;&gt; is engaged, else gives you nullopt?<br>
<br>Furthermore, we could apply this to any function, of any types?<br><br>=
</div><div>Foo someFunc(T1 t1, T2 t2, T3 t3);<br><br></div><div>pass in an =
empty optional&lt;Tn&gt; into any of these and you get back an empty option=
al&lt;Foo&gt;?<br>
<br></div><div>Is that the request?<br><br></div><div>In C++, something lik=
e:<br><br></div><div>template &lt;typename F&gt; // F is a Function signatu=
re<br></div><div>optional&lt;result_of&lt;F&gt;::type&gt; apply(F f, option=
al&lt;arg&lt;F,0&gt;::type&gt; a1, optional&lt;arg&lt;F,1&gt;::type&gt; a2,=
 etc...)<br>
{<br></div><div>=A0=A0 if (!a1 || !a2 || ...)<br></div><div>=A0=A0=A0=A0=A0=
 return optional&lt;result_of&lt;F&gt;::type&gt;(); // empty<br><br></div><=
div>=A0=A0 return f(*a1, *a2, ...);<br>}<br><br></div><div>use:<br><br></di=
v><div>string function(int x, double y);<br>
<br></div><div>optional&lt;double&gt; ymaybe =3D ...;<br><br></div><div>opt=
ional&lt;string&gt; res =3D apply(function, 12, ymaybe);<br><br>?<br><br></=
div><div>Not as pretty as in a functional language, but I suspect it is doa=
ble.<br>
</div><div><br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b34382c6cf91804db20b0d7--

.

------=_Part_23_29829632.1366834732801
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, April 24, 2013 9:55:52 PM UTC+2, Tony V E wrote:
>
>
> I'm still trying to understand what you are asking for (since my Haskell
> is, let's say "rusty" or "nonexistent").
> Let's try it this way:
>
> if you had a function int func(int) , would you like to somehow
> *automatically* have the function optional<int> func(optional<int>)?
>
> ie pass an optional<int> into func gives you the correct int result if the
> optional<> is engaged, else gives you nullopt?
>

Yes. In Haskell, `fmap` can be seen as either doing the application
automatically for you (I described it that way) or through partial
application basically transforming the function. I think both ways might
work in C++.

Furthermore, we could apply this to any function, of any types?
>

Foo someFunc(T1 t1, T2 t2, T3 t3);
>
> pass in an empty optional<Tn> into any of these and you get back an empty
> optional<Foo>?
>

> Is that the request?
>

That was not something I suggested (yet :) ), I should've made myself
clearer. In Haskell, it easily works through partial application, but C++
isn't so nice with that. Not sure if it's reasonable to take that to
std::optional. With an implementation like this:


> In C++, something like:
>
> template <typename F> // F is a Function signature
> optional<result_of<F>::type> apply(F f, optional<arg<F,0>::type> a1,
> optional<arg<F,1>::type> a2, etc...)
> {
>    if (!a1 || !a2 || ...)
>       return optional<result_of<F>::type>(); // empty
>
>    return f(*a1, *a2, ...);
> }
>

there's the problem of overloaded, default-argumented and templated
functions (operator()) again.

I think I need to think about this some more.

--

---
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/?hl=en.



------=_Part_23_29829632.1366834732801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, April 24, 2013 9:55:52 PM UTC+2, Tony V E wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div class=3D"gma=
il_quote"><div>I'm still trying to understand what you are asking for (sinc=
e my Haskell is, let's say "rusty" or "nonexistent").<br>
Let's try it this way:<br><br></div><div>if you had a function int func(int=
) , would you like to somehow *automatically* have the function optional&lt=
;int&gt; func(optional&lt;int&gt;)? <br><div><br></div>ie
 pass an optional&lt;int&gt; into func gives you the correct int result=20
if the optional&lt;&gt; is engaged, else gives you nullopt?</div></div></di=
v></div></blockquote><div><br>Yes. In Haskell, `fmap` can be seen as either=
 doing the application automatically for you (I described it that way) or t=
hrough partial application basically transforming the function. I think bot=
h ways might work in C++. <br>
<br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Furthermore, =
we could apply this to any function, of any types?<br></blockquote><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>Foo someFunc(T1 t1, T2 t2, T3 t3);<br><br></div><=
div>pass in an empty optional&lt;Tn&gt; into any of these and you get back =
an empty optional&lt;Foo&gt;?<br></div></div></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"><div><div class=3D=
"gmail_quote"><div>
<br></div><div>Is that the request?<br></div></div></div></div></blockquote=
><div><br>That was not something I suggested (yet :) ), I should've made my=
self clearer. In Haskell, it easily works through partial application, but =
C++ isn't so nice with that. Not sure if it's reasonable to take that to st=
d::optional. With an implementation like this:<br></div><div>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div></div><div>In C++, something like:<br><br></div><div>=
template &lt;typename F&gt; // F is a Function signature<br></div><div>opti=
onal&lt;result_of&lt;F&gt;::type&gt; apply(F f, optional&lt;arg&lt;F,0&gt;:=
:type&gt; a1, optional&lt;arg&lt;F,1&gt;::type&gt; a2, etc...)<br>
{<br></div><div>&nbsp;&nbsp; if (!a1 || !a2 || ...)<br></div><div>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; return optional&lt;result_of&lt;F&gt;::type&gt;()<wbr=
>; // empty<br><br></div><div>&nbsp;&nbsp; return f(*a1, *a2, ...);<br>}<br=
></div></div></div></div></blockquote><div><br>there's the problem of overl=
oaded, default-argumented and templated functions (operator()) again.<br><b=
r>I think I need to think about this some more.<br></div>

<p></p>

-- <br />
&nbsp;<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_23_29829632.1366834732801--

.