------=_Part_109_19138881.1366793364875
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 is barely any benefit of using std::optional except that to
interface makes it more explicitly that the function is partial and can
fail.

--

---
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_109_19138881.1366793364875
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 aspe=
ct of Maybe/option types in functional languages then just completely ignor=
es the rest. std::optional has all the disadvantages of using pointer retur=
n types and only has one advantage which is not needing heap allocations.<b=
r><br>Maybe/option types in functional language are written with algebraic =
data-types and decomposed with pattern matching and case expressions, the c=
ompiler does case-analysis to throw errors/warnings at compile-time when yo=
u do not cover all the cases of an algebraic data-type. We do not have thes=
e 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 hel=
p the matter that std::optional is being treated syntactically like a point=
er.<br><br>Where are all the typical higher-level functions I'd expect from=
 a Maybe type. There is barely any benefit of using std::optional except th=
at to interface makes it more explicitly that the function is partial and c=
an fail.<br><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_109_19138881.1366793364875--

.

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

On Wed, Apr 24, 2013 at 4:49 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. 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 is barely any benefit of using std::optional except that to
> interface makes it more explicitly that the function is partial and can
> fail.
>
>
Could you give some code examples as to what you would want to do with a
better optional?

Tony

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--f46d0407153316232104db1e4a5e
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 4:49 AM, snk_kid <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.husse=
in@googlemail.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 by the overly pointer interface. This propo=
sal seems to capture one small aspect of Maybe/option types in functional l=
anguages then just completely ignores the rest. std::optional has all the d=
isadvantages 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 da=
ta-types and decomposed with pattern matching and case expressions, the com=
piler 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 fa=
il 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&#39;d expect from a =
Maybe type. There is barely any benefit of using std::optional except that =
to interface makes it more explicitly that the function is partial and can =
fail.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>

</font></span></blockquote><div><br></div><div>Could you give some code exa=
mples as to what you would want to do with a better optional?<br><br></div>=
<div>Tony<br>=A0<br></div></div></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 />

--f46d0407153316232104db1e4a5e--

.

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

Ah I see the thread is occurring elsewhere.  Ignore.


On Wed, Apr 24, 2013 at 1:04 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
>
> On Wed, Apr 24, 2013 at 4:49 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. 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 is barely any benefit of using std::optional except that to
>> interface makes it more explicitly that the function is partial and can
>> fail.
>>
>>
> Could you give some code examples as to what you would want to do with a
> better optional?
>
> Tony
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



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

<div dir=3D"ltr">Ah I see the thread is occurring elsewhere.=A0 Ignore.<br>=
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Apr 24, 2013 at 1:04 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wro=
te:<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"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On Wed, Apr 24, 20=
13 at 4:49 AM, snk_kid <span dir=3D"ltr">&lt;<a href=3D"mailto:korcan.husse=
in@googlemail.com" target=3D"_blank">korcan.hussein@googlemail.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 by the overly pointer interface. This propo=
sal seems to capture one small aspect of Maybe/option types in functional l=
anguages then just completely ignores the rest. std::optional has all the d=
isadvantages 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 da=
ta-types and decomposed with pattern matching and case expressions, the com=
piler 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 fa=
il 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&#39;d expect from a =
Maybe type. There is barely any benefit of using std::optional except that =
to interface makes it more explicitly that the function is partial and can =
fail.<span><font color=3D"#888888"><br>

<br>

</font></span></blockquote><div><br></div></div><div>Could you give some co=
de examples as to what you would want to do with a better optional?<span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></div><span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><div>
Tony<br>=A0<br></div></font></span></div></div></div>
</blockquote></div><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 />

--047d7b3441feeb55e704db1e98aa--

.