Hi, all!

Rust and Scala have types similar to std::optional:
https://doc.rust-lang.org/std/option/index.html
http://www.scala-lang.org/api/2.11.8/#scala.Option

Both of these languages support iterating over Option, (as if it was a container
with either 0 or 1 elements). Another feature which C++'s optional lacks
(compared to Rust and Scala) is transforming the value contained in std::optional.

I.e.:

std::string to_string(int i);
std::optional<std::string> to_opt_string(int i);

int main()
{
    std::optional<int> test { 1 };
    auto res = test.transform(to_string);
    auto res2 = test.flat_transform(to_opt_string);

    // res and res2 are of type std::optional<std::string>
}

What do you think about adding these features?

--
Mikhail Maltsev

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69680943-5fed-2ce1-c194-021f780f2b23%40gmail.com.

.

------=_Part_8588_1046013195.1474827848748
Content-Type: multipart/alternative;
 boundary="----=_Part_8589_337094738.1474827848749"

------=_Part_8589_337094738.1474827848749
Content-Type: text/plain; charset=UTF-8

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/in38mPp2NiU

On Sunday, September 25, 2016 at 9:34:49 PM UTC+8, Mikhail Maltsev wrote:
>
> Hi, all!
>
> Rust and Scala have types similar to std::optional:
> https://doc.rust-lang.org/std/option/index.html
> http://www.scala-lang.org/api/2.11.8/#scala.Option
>
> Both of these languages support iterating over Option, (as if it was a
> container
> with either 0 or 1 elements). Another feature which C++'s optional lacks
> (compared to Rust and Scala) is transforming the value contained in
> std::optional.
>
> I.e.:
>
> std::string to_string(int i);
> std::optional<std::string> to_opt_string(int i);
>
> int main()
> {
>     std::optional<int> test { 1 };
>     auto res = test.transform(to_string);
>     auto res2 = test.flat_transform(to_opt_string);
>
>     // res and res2 are of type std::optional<std::string>
> }
>
> What do you think about adding these features?
>
> --
> Mikhail Maltsev
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40bc4024-03df-4a51-a2eb-f0bf5d55ebcb%40isocpp.org.

------=_Part_8589_337094738.1474827848749
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/in38mPp2NiU<br><br>On Sunday, September 25, 2016 at 9:34:49 PM UTC=
+8, Mikhail Maltsev wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi, =
all!
<br>
<br>Rust and Scala have types similar to std::optional:
<br><a href=3D"https://doc.rust-lang.org/std/option/index.html" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Foption%2Findex.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuXJ3AP-ZSM_1GamoW8PW4Z1AHug&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttp=
s%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Foption%2Findex.html\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNEuXJ3AP-ZSM_1GamoW8PW4Z1AHug&#39;;return true;">https:=
//doc.rust-lang.org/std/<wbr>option/index.html</a>
<br><a href=3D"http://www.scala-lang.org/api/2.11.8/#scala.Option" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.scala-lang.org%2Fapi%2F2.11.8%2F%23scala.=
Option\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGnGP0Sl5V-ROnE8esbcwtAOVPTA=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fwww.scala-lang.org%2Fapi%2F2.11.8%2F%23scala.Option\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGnGP0Sl5V-ROnE8esbcwtAOVPTA&#39;;return =
true;">http://www.scala-lang.org/api/<wbr>2.11.8/#scala.Option</a>
<br>
<br>Both of these languages support iterating over Option, (as if it was a =
container
<br>with either 0 or 1 elements). Another feature which C++&#39;s optional =
lacks
<br>(compared to Rust and Scala) is transforming the value contained in std=
::optional.
<br>
<br>I.e.:
<br>
<br>std::string to_string(int i);
<br>std::optional&lt;std::string&gt; to_opt_string(int i);
<br>
<br>int main()
<br>{
<br>=C2=A0 =C2=A0 std::optional&lt;int&gt; test { 1 };
<br>=C2=A0 =C2=A0 auto res =3D test.transform(to_string);
<br>=C2=A0 =C2=A0 auto res2 =3D test.flat_transform(to_opt_<wbr>string);
<br>
<br>=C2=A0 =C2=A0 // res and res2 are of type std::optional&lt;std::string&=
gt;
<br>}
<br>
<br>What do you think about adding these features?
<br>
<br>--=20
<br>Mikhail Maltsev
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40bc4024-03df-4a51-a2eb-f0bf5d55ebcb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40bc4024-03df-4a51-a2eb-f0bf5d55ebcb=
%40isocpp.org</a>.<br />

------=_Part_8589_337094738.1474827848749--

------=_Part_8588_1046013195.1474827848748--

.

------=_Part_229_1251082558.1474837161422
Content-Type: multipart/alternative;
 boundary="----=_Part_230_1102813670.1474837161422"

------=_Part_230_1102813670.1474837161422
Content-Type: text/plain; charset=UTF-8



On Sunday, September 25, 2016 at 9:34:49 AM UTC-4, Mikhail Maltsev wrote:
>
> Hi, all!
>
> Rust and Scala have types similar to std::optional:
> https://doc.rust-lang.org/std/option/index.html
> http://www.scala-lang.org/api/2.11.8/#scala.Option
>
> Both of these languages support iterating over Option, (as if it was a
> container
> with either 0 or 1 elements).


It seems to me that you can write an `as_range` function that takes
`optional` easily enough. But really, iterating over an optional isn't
something people want to do often enough to stick it in the standard
library.

Another feature which C++'s optional lacks
> (compared to Rust and Scala) is transforming the value contained in
> std::optional.
>

It seems to me that this is something you can write as a simple helper
function, one which takes an optional and a function, then uses
`std::invoke` on the optional if it is engaged.

Like range optional iteration, it is something that doesn't come up
frequently enough to need a standard library function.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/dea182f9-f8be-4b1b-b408-403bb4c1bb92%40isocpp.org.

------=_Part_230_1102813670.1474837161422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, September 25, 2016 at 9:34:49 AM UTC-4,=
 Mikhail Maltsev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi, all=
!
<br>
<br>Rust and Scala have types similar to std::optional:
<br><a href=3D"https://doc.rust-lang.org/std/option/index.html" target=3D"_=
blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Foption%2Findex.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEuXJ3AP-ZSM_1GamoW8PW4Z1AHug&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttp=
s%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Foption%2Findex.html\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNEuXJ3AP-ZSM_1GamoW8PW4Z1AHug&#39;;return true;">https:=
//doc.rust-lang.org/std/<wbr>option/index.html</a>
<br><a href=3D"http://www.scala-lang.org/api/2.11.8/#scala.Option" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.scala-lang.org%2Fapi%2F2.11.8%2F%23scala.=
Option\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGnGP0Sl5V-ROnE8esbcwtAOVPTA=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fwww.scala-lang.org%2Fapi%2F2.11.8%2F%23scala.Option\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGGnGP0Sl5V-ROnE8esbcwtAOVPTA&#39;;return =
true;">http://www.scala-lang.org/api/<wbr>2.11.8/#scala.Option</a>
<br>
<br>Both of these languages support iterating over Option, (as if it was a =
container
<br>with either 0 or 1 elements).</blockquote><div><br>It seems to me that =
you can write an `as_range` function that takes `optional` easily enough. B=
ut really, iterating over an optional isn&#39;t something people want to do=
 often enough to stick it in the standard library.<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">Another feature which C++&#39;s optional =
lacks
<br>(compared to Rust and Scala) is transforming the value contained in std=
::optional.
<br></blockquote><div><br>It seems to me that this is something you can wri=
te as a simple helper function, one which takes an optional and a function,=
 then uses `std::invoke` on the optional if it is engaged.</div><br>Like ra=
nge optional iteration, it is something that doesn&#39;t come up frequently=
 enough to need a standard library function.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dea182f9-f8be-4b1b-b408-403bb4c1bb92%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dea182f9-f8be-4b1b-b408-403bb4c1bb92=
%40isocpp.org</a>.<br />

------=_Part_230_1102813670.1474837161422--

------=_Part_229_1251082558.1474837161422--

.

------=_Part_10082_759645845.1474870261531
Content-Type: multipart/alternative;
 boundary="----=_Part_10083_729625459.1474870261531"

------=_Part_10083_729625459.1474870261531
Content-Type: text/plain; charset=UTF-8

On Sunday, September 25, 2016 at 1:59:21 PM UTC-7, Nicol Bolas wrote:
>
> Like range optional iteration, it is something that doesn't come up
> frequently enough to need a standard library function.
>

Checking if an optional is engaged and then invoking code over it is the
whole point of an optional. Doing it _safely_ without being exceedingly
easy to misuse is also a very key functionality, something which today
requires a good static analyzer to use.

This is asking for essential limited pattern matching in pure-library form
for optional. Pattern matching being something just about everyone wants;
see https://github.com/solodon4/Mach7 for instance.

The interface in C++17 is unsafe. It goes against the many lessons learned
in the languages that pioneered the very concept of
optionals/variants/algebraic-types. With C++ optional, you can just *opt
and get a thrown exception; now we have Java's NullPointerException ported
into C++, essentially.

The video isn't available yet, but you should really see Ben's CppCon '16
talk "Using Types Effectively" that explains the better way to use types
like optional that we have learned from functional-programming. (The talk's
slide content is available on his GitHub
at https://github.com/elbeno/using-types-effectively/blob/master/presentation.org
..) I might also suggest reading articles on using optional types that come
straight from the FP world, e.g. articles
like https://8thlight.com/blog/uku-taht/2015/04/29/using-the-option-type-effectively.html
..

Better use of an optional _mandates_ the use of conditional unpacking.
Traditionally, this was done with a full-weight pattern matching system:

// painfully verbose... but always safe, guaranteed (invented syntax, of
course)

match (opt) {
  case some(&val): use(val);
  case none: ignore_or_something();
}


 More modern improvements allow this to be done in a simpler conditional
statement:

// short and simple... not possible in C++ as a library

if (auto& val = some(opt))

  use(val);


C++ doesn't have support for that in the language directly; the above would
check the truth-iness of the unpacked value, not whether the value can be
unpacked in the first place. The only ways to emulate it would be as unsafe
as optional is today (in fact would just _be_ what optional is today). What
we do have in C++ that can be used to emulate this, however, is the
for-range statement:

// semantic abuse of for-range, but it works in C++ today with no language
changes,

// and doesn't suffer the problems of lambdas ... but it can't support an
else clause

for (auto& val : opt)

  use(val);


// negate the check - none returns a one-element range of std::ignore or
something if the optional is disengaged

for (auto : none(opt))

  ignore_or_something();


We could also use lambdas/functions as you suggested, but that breaks in
some fun ways; namely, it disables the use of return/break from the body.
The best you can do would be a signature like the below. It's also just a
pain to use reliably in loops, meaning you have to resort to _really_ ugly
uses of find_if instead.

template <class A, class U, class V>
common_type_t<U, V> match(optional<A> value, function<U(A)> engaged,
function<V()> disengaged);


// usable in the tail position of a function only

return match(val,
  [](T& val){ return use(val); },
  []{ return ignore_or_something(); });


// this won't actually work...

for (auto& opt : optionals_container)

  match(opt,
    [](T& val){
      if (condition(val))
        return val; // oops, this isn't useful, it "continues" in the loop
and doesn't return/break
    }, []{ something_else(); });


// find_if suffers from the same general problem: you are able to use the
return value incorrectly/unsafely

auto it = std::find_if(optionals_container.begin(),
optionals_container.end(), [](optional<T>& opt){
  if (opt && conditional(*opt))
    return true;
  else {
    something_else();
    return false;
  }
});
auto& val = **opt; // what if it == end()? are you _sure_ the returned
value is an engaged optional? the compiler can't help check your assumption

return val;


Now, all that said, I don't in my heart _like_ the idea of abusing the
for-range statement for this purpose. But, as a library-only
implementation, it's really the best option *ahem* that we have right now.
I'd prefer real pattern matching, but the specifics aside, the claim that
we don't need this or that it's an uncommon need is mistaken.

On a related note, the lack of a ::map method or its like on optional is
also a huge shortcoming. Such a method would actually help remove a ton of
the uses of the for-range usage discussed here:

// val becomes optional<B>, and is engaged iff opt was engaged

auto val = opt.map([](auto& v){ return B(v); });


// could be even simpler if we had a std::construct which I'll include below

auto val = opt.map(construct<B>);



std::construct<T>

template <class T>
struct constructor_impl {
  template <class... Args>
  constexpr T operator()(Args&&... args) const { return
T(std::forward<Args>(args)...); }
};

template <class T>
constexpr auto construct = constructor_impl<T>{};

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c531d3e3-3414-413d-8864-ac1810a9b20f%40isocpp.org.

------=_Part_10083_729625459.1474870261531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, September 25, 2016 at 1:59:21 PM UTC-7, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Li=
ke range optional iteration, it is something that doesn&#39;t come up frequ=
ently enough to need a standard library function.<br></div></blockquote><di=
v><br></div><div>Checking if an optional is engaged and then invoking code =
over it is the whole point of an optional. Doing it _safely_ without being =
exceedingly easy to misuse is also a very key functionality, something whic=
h today requires a good static analyzer to use.<br></div><div><br></div><di=
v>This is asking for essential limited pattern matching in pure-library for=
m for optional. Pattern matching being something just about everyone wants;=
 see=C2=A0https://github.com/solodon4/Mach7 for instance.<br></div><div><br=
></div><div>The interface in C++17 is unsafe. It goes against the many less=
ons learned in the languages that pioneered the very concept of optionals/v=
ariants/algebraic-types. With C++ optional, you can just *opt and get a thr=
own exception; now we have Java&#39;s NullPointerException ported into C++,=
 essentially.</div><div><br></div><div>The video isn&#39;t available yet, b=
ut you should really see Ben&#39;s CppCon &#39;16 talk &quot;Using Types Ef=
fectively&quot; that explains the better way to use types like optional tha=
t we have learned from functional-programming. (The talk&#39;s slide conten=
t is available on his GitHub at=C2=A0https://github.com/elbeno/using-types-=
effectively/blob/master/presentation.org .) I might also suggest reading ar=
ticles on using optional types that come straight from the FP world, e.g. a=
rticles like=C2=A0https://8thlight.com/blog/uku-taht/2015/04/29/using-the-o=
ption-type-effectively.html .</div><div><br></div><div>Better use of an opt=
ional _mandates_ the use of conditional unpacking. Traditionally, this was =
done with a full-weight pattern matching system:</div><div><br></div><block=
quote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>// pai=
nfully verbose... but always safe, guaranteed (invented syntax, of course)<=
/div></blockquote><blockquote style=3D"margin: 0 0 0 40px; border: none; pa=
dding: 0px;"><div>match (opt) {</div><div>=C2=A0 case some(&amp;val): use(v=
al);</div><div>=C2=A0 case none: ignore_or_something();</div><div>}</div></=
blockquote><div><br></div><div>=C2=A0More modern improvements allow this to=
 be done in a simpler conditional statement:</div><div><br></div><div><bloc=
kquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>// sh=
ort and simple... not possible in C++ as a library</div></blockquote></div>=
<blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>=
if (auto&amp; val =3D some(opt))</div></blockquote><blockquote style=3D"mar=
gin: 0 0 0 40px; border: none; padding: 0px;"><div>=C2=A0 use(val);=C2=A0</=
div></blockquote><div><br></div><div>C++ doesn&#39;t have support for that =
in the language directly; the above would check the truth-iness of the unpa=
cked value, not whether the value can be unpacked in the first place. The o=
nly ways to emulate it would be as unsafe as optional is today (in fact wou=
ld just _be_ what optional is today). What we do have in C++ that can be us=
ed to emulate this, however, is the for-range statement:</div><div><br></di=
v><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><di=
v>// semantic abuse of for-range, but it works in C++ today with no languag=
e changes,</div></blockquote><blockquote style=3D"margin: 0 0 0 40px; borde=
r: none; padding: 0px;"><div>// and doesn&#39;t suffer the problems of lamb=
das ... but it can&#39;t support an else clause</div></blockquote><blockquo=
te style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>for (auto=
&amp; val : opt)</div></blockquote><blockquote style=3D"margin: 0 0 0 40px;=
 border: none; padding: 0px;"><div>=C2=A0 use(val);</div></blockquote><div>=
<br></div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0=
px;"><div>// negate the check - none returns a one-element range of std::ig=
nore or something if the optional is disengaged</div></blockquote><blockquo=
te style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>for (auto=
 : none(opt))</div></blockquote><blockquote style=3D"margin: 0 0 0 40px; bo=
rder: none; padding: 0px;"><div>=C2=A0 ignore_or_something();</div></blockq=
uote><div><br></div><div>We could also use lambdas/functions as you suggest=
ed, but that breaks in some fun ways; namely, it disables the use of return=
/break from the body. The best you can do would be a signature like the bel=
ow. It&#39;s also just a pain to use reliably in loops, meaning you have to=
 resort to _really_ ugly uses of find_if instead.</div><div><br></div><bloc=
kquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>templ=
ate &lt;class A, class U, class V&gt;</div><div>common_type_t&lt;U, V&gt; m=
atch(optional&lt;A&gt; value, function&lt;U(A)&gt; engaged, function&lt;V()=
&gt; disengaged);</div></blockquote><div><br></div><div><blockquote style=
=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>// usable in the =
tail position of a function only</div></blockquote></div><blockquote style=
=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>return match(val,=
</div><div>=C2=A0 [](T&amp; val){ return use(val); },</div><div>=C2=A0 []{ =
return ignore_or_something(); });</div></blockquote><div><br></div><div><bl=
ockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>// =
this won&#39;t actually work...</div></blockquote></div><blockquote style=
=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>for (auto&amp; op=
t : optionals_container)</div></blockquote><blockquote style=3D"margin: 0 0=
 0 40px; border: none; padding: 0px;"><div>=C2=A0 match(opt,</div><div>=C2=
=A0 =C2=A0 [](T&amp; val){</div><div>=C2=A0 =C2=A0 =C2=A0 if (condition(val=
))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return val; // oops, this isn&#39;=
t useful, it &quot;continues&quot; in the loop and doesn&#39;t return/break=
</div><div>=C2=A0 =C2=A0 }, []{ something_else(); });</div></blockquote><di=
v><br></div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding:=
 0px;"><div>// find_if suffers from the same general problem: you are able =
to use the return value incorrectly/unsafely</div></blockquote><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>auto it =3D =
std::find_if(optionals_container.begin(), optionals_container.end(), [](opt=
ional&lt;T&gt;&amp; opt){</div><div>=C2=A0 if (opt &amp;&amp; conditional(*=
opt))</div><div>=C2=A0 =C2=A0 return true;</div><div>=C2=A0 else {</div><di=
v>=C2=A0 =C2=A0 something_else();</div><div>=C2=A0 =C2=A0 return false;</di=
v><div>=C2=A0 }</div><div>});</div><div>auto&amp; val =3D **opt; // what if=
 it =3D=3D end()? are you _sure_ the returned value is an engaged optional?=
 the compiler can&#39;t help check your assumption</div></blockquote><block=
quote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>return=
 val;</div></blockquote><div><br></div><div>Now, all that said, I don&#39;t=
 in my heart _like_ the idea of abusing the for-range statement for this pu=
rpose. But, as a library-only implementation, it&#39;s really the best opti=
on *ahem* that we have right now. I&#39;d prefer real pattern matching, but=
 the specifics aside, the claim that we don&#39;t need this or that it&#39;=
s an uncommon need is mistaken.</div><div><br></div><div>On a related note,=
 the lack of a ::map method or its like on optional is also a huge shortcom=
ing. Such a method would actually help remove a ton of the uses of the for-=
range usage discussed here:</div><div><br></div><div><blockquote style=3D"m=
argin: 0 0 0 40px; border: none; padding: 0px;"><div>// val becomes optiona=
l&lt;B&gt;, and is engaged iff opt was engaged</div></blockquote></div><blo=
ckquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>auto=
 val =3D opt.map([](auto&amp; v){ return B(v); });</div></blockquote><div><=
br></div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0p=
x;"><div>// could be even simpler if we had a std::construct which I&#39;ll=
 include below</div></blockquote><blockquote style=3D"margin: 0 0 0 40px; b=
order: none; padding: 0px;"><div>auto val =3D opt.map(construct&lt;B&gt;);=
=C2=A0</div></blockquote><div><br></div><div><br></div><div>std::construct&=
lt;T&gt;</div><div><br></div><blockquote style=3D"margin: 0 0 0 40px; borde=
r: none; padding: 0px;"><div>template &lt;class T&gt;</div><div>struct cons=
tructor_impl {</div><div>=C2=A0 template &lt;class... Args&gt;</div><div>=
=C2=A0 constexpr T operator()(Args&amp;&amp;... args) const { return T(std:=
:forward&lt;Args&gt;(args)...); }</div><div>};</div><div><br></div><div>tem=
plate &lt;class T&gt;</div><div>constexpr auto construct =3D=C2=A0construct=
or_impl&lt;T&gt;{};</div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c531d3e3-3414-413d-8864-ac1810a9b20f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c531d3e3-3414-413d-8864-ac1810a9b20f=
%40isocpp.org</a>.<br />

------=_Part_10083_729625459.1474870261531--

------=_Part_10082_759645845.1474870261531--

.

On 26 September 2016 at 09:11, Sean Middleditch
<sean.middleditch@gmail.com> wrote:
> The interface in C++17 is unsafe. It goes against the many lessons learned
> in the languages that pioneered the very concept of
> optionals/variants/algebraic-types. With C++ optional, you can just *opt and
> get a thrown exception; now we have Java's NullPointerException ported into
> C++, essentially.


*opt doesn't throw.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUabDrmpcEeTKedU0JUVsDoMA93aBtboB%2BhyYe%3DZjPLaOg%40mail.gmail.com.

.

--94eb2c05c364d38ac2053d63d762
Content-Type: text/plain; charset=UTF-8

2016-09-26 8:11 GMT+02:00 Sean Middleditch <sean.middleditch@gmail.com>:


> Better use of an optional _mandates_ the use of conditional unpacking.
> Traditionally, this was done with a full-weight pattern matching system:
>
> // painfully verbose... but always safe, guaranteed (invented syntax, of
> course)
>
> match (opt) {
>   case some(&val): use(val);
>   case none: ignore_or_something();
> }
>
>
>  More modern improvements allow this to be done in a simpler conditional
> statement:
>
> // short and simple... not possible in C++ as a library
>
> if (auto& val = some(opt))
>
>   use(val);
>
>
> C++ doesn't have support for that in the language directly; the above
> would check the truth-iness of the unpacked value, not whether the value
> can be unpacked in the first place. The only ways to emulate it would be as
> unsafe as optional is today (in fact would just _be_ what optional is
> today). What we do have in C++ that can be used to emulate this, however,
> is the for-range statement:
>
> // semantic abuse of for-range, but it works in C++ today with no language
> changes,
>
> // and doesn't suffer the problems of lambdas ... but it can't support an
> else clause
>
> for (auto& val : opt)
>
>   use(val);
>
>
> // negate the check - none returns a one-element range of std::ignore or
> something if the optional is disengaged
>
> for (auto : none(opt))
>
>   ignore_or_something();
>
>
>
I know that it's an extra unpacking line and more lines than pattern
matching version but this works with C++17:
  if(opt) // or alternative opt.has_value() for non experimental version of
optional
  {
      auto& val = opt.value();
  }
  else
  {
      // handle no value
  }

It looks much better to me than for loop emulation hack and good enough to
wait for pattern matching. You could also write an invoke_if (or
invoke_if_else) functor that executes a lambda but only if optional
contains a value which would probably be even more in the direction of
functional programming and can emulate pattern matching.

Regards,
Domen

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ%2BouzY%2BhKjOHLd8EC5OTNaF3nBgRu_A3G-Xqv%3D65b8mg%40mail.gmail.com.

--94eb2c05c364d38ac2053d63d762
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2016-09-26 8:11 GMT+02:00 Sean Middleditch <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditch@=
gmail.com</a>&gt;</span>:<br><br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><span class=3D"gmail-"></span><br><div dir=3D"ltr"><div>Better use =
of an optional _mandates_ the use of conditional unpacking. Traditionally, =
this was done with a full-weight pattern matching system:</div><div><br></d=
iv><blockquote style=3D"margin:0px 0px 0px 40px;border-width:medium;border-=
style:none;border-color:-moz-use-text-color;padding:0px"><div>// painfully =
verbose... but always safe, guaranteed (invented syntax, of course)</div></=
blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border-width:medium=
;border-style:none;border-color:-moz-use-text-color;padding:0px"><div>match=
 (opt) {</div><div>=C2=A0 case some(&amp;val): use(val);</div><div>=C2=A0 c=
ase none: ignore_or_something();</div><div>}</div></blockquote><div><br></d=
iv><div>=C2=A0More modern improvements allow this to be done in a simpler c=
onditional statement:</div><div><br></div><div><blockquote style=3D"margin:=
0px 0px 0px 40px;border-width:medium;border-style:none;border-color:-moz-us=
e-text-color;padding:0px"><div>// short and simple... not possible in C++ a=
s a library</div></blockquote></div><blockquote style=3D"margin:0px 0px 0px=
 40px;border-width:medium;border-style:none;border-color:-moz-use-text-colo=
r;padding:0px"><div>if (auto&amp; val =3D some(opt))</div></blockquote><blo=
ckquote style=3D"margin:0px 0px 0px 40px;border-width:medium;border-style:n=
one;border-color:-moz-use-text-color;padding:0px"><div>=C2=A0 use(val);=C2=
=A0</div></blockquote><div><br></div><div>C++ doesn&#39;t have support for =
that in the language directly; the above would check the truth-iness of the=
 unpacked value, not whether the value can be unpacked in the first place. =
The only ways to emulate it would be as unsafe as optional is today (in fac=
t would just _be_ what optional is today). What we do have in C++ that can =
be used to emulate this, however, is the for-range statement:</div><div><br=
></div><blockquote style=3D"margin:0px 0px 0px 40px;border-width:medium;bor=
der-style:none;border-color:-moz-use-text-color;padding:0px"><div>// semant=
ic abuse of for-range, but it works in C++ today with no language changes,<=
/div></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border-width=
:medium;border-style:none;border-color:-moz-use-text-color;padding:0px"><di=
v>// and doesn&#39;t suffer the problems of lambdas ... but it can&#39;t su=
pport an else clause</div></blockquote><blockquote style=3D"margin:0px 0px =
0px 40px;border-width:medium;border-style:none;border-color:-moz-use-text-c=
olor;padding:0px"><div>for (auto&amp; val : opt)</div></blockquote><blockqu=
ote style=3D"margin:0px 0px 0px 40px;border-width:medium;border-style:none;=
border-color:-moz-use-text-color;padding:0px"><div>=C2=A0 use(val);</div></=
blockquote><div><br></div><blockquote style=3D"margin:0px 0px 0px 40px;bord=
er-width:medium;border-style:none;border-color:-moz-use-text-color;padding:=
0px"><div>// negate the check - none returns a one-element range of std::ig=
nore or something if the optional is disengaged</div></blockquote><blockquo=
te style=3D"margin:0px 0px 0px 40px;border-width:medium;border-style:none;b=
order-color:-moz-use-text-color;padding:0px"><div>for (auto : none(opt))</d=
iv></blockquote><blockquote style=3D"margin:0px 0px 0px 40px;border-width:m=
edium;border-style:none;border-color:-moz-use-text-color;padding:0px"><div>=
=C2=A0 ignore_or_something();</div></blockquote><br></div></blockquote><div=
><br></div><div>I know that it&#39;s an extra unpacking line and more lines=
 than pattern matching version but this works with C++17: <br>=C2=A0 if(opt=
) // or alternative <span class=3D"gmail-mw-geshi gmail-cpp gmail-source-cp=
p">opt.has_value<span class=3D"gmail-br0">(</span><span class=3D"gmail-br0"=
>) for non experimental version of optional</span></span><br>=C2=A0 {<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto&amp; val =3D opt.value();<br>=C2=A0 }<b=
r></div><div>=C2=A0 else<br>=C2=A0 {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 // handle no value<br></div><div>=C2=A0 }<br><br></div><div>It looks=
 much better to me than for loop emulation hack and good enough to wait for=
 pattern matching. You could also write an invoke_if (or invoke_if_else) fu=
nctor that executes a lambda but only if optional contains a value which wo=
uld probably be even more in the direction of functional programming and ca=
n emulate pattern matching.<br><br></div><div>Regards,<br></div><div>Domen<=
br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ%2BouzY%2BhKjOHLd8EC5OTNaF3nB=
gRu_A3G-Xqv%3D65b8mg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ%2B=
ouzY%2BhKjOHLd8EC5OTNaF3nBgRu_A3G-Xqv%3D65b8mg%40mail.gmail.com</a>.<br />

--94eb2c05c364d38ac2053d63d762--

.

--001a1140e92e941585053d6b52c8
Content-Type: text/plain; charset=UTF-8

On Sun, Sep 25, 2016 at 11:16 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
> *opt doesn't throw.
>

So it does not. Which is, arguably, worse. I mean, I staunchly dislike
exceptions, but adding yet another unnecessary set of
easy-to-accidentally-invoke UB is not great.

Sadly, the committee/community wanted optional sooner rather than later,
even if the language isn't ready to do it right yet, so here we are. :)

Point stands. Easy-to-grep and safer-to-teach access to
optional/variant/etc. is something that should be in the library. Since
we'd be targetting C++20 at a minimum, now, though, it's perhaps better to
think about how any language features landing in that timeframe could
potentially be used to make the access even better (because no, for-range
abuse isn't great).


--
Sean Middleditch
http://seanmiddleditch.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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFhYbVgUdCb3OW6M6UoQmLYA8dLROGCRZHN01fybB8-SRA%40mail.gmail.com.

--001a1140e92e941585053d6b52c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Sep 25, 2016 at 11:16 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span =
class=3D""><br>
</span>*opt doesn&#39;t throw.<br></blockquote><div><br></div><div>So it do=
es not. Which is, arguably, worse. I mean, I staunchly dislike exceptions, =
but adding yet another unnecessary set of easy-to-accidentally-invoke UB is=
 not great.</div><div><br></div><div>Sadly, the committee/community wanted =
optional sooner rather than later, even if the language isn&#39;t ready to =
do it right yet, so here we are. :)</div><div><br></div><div>Point stands. =
Easy-to-grep and safer-to-teach access to optional/variant/etc. is somethin=
g that should be in the library. Since we&#39;d be targetting C++20 at a mi=
nimum, now, though, it&#39;s perhaps better to think about how any language=
 features landing in that timeframe could potentially be used to make the a=
ccess even better (because no, for-range abuse isn&#39;t great).</div><div>=
<br></div><div><br></div></div>-- <br><div class=3D"gmail_signature" data-s=
martmail=3D"gmail_signature">Sean Middleditch<br><a href=3D"http://seanmidd=
leditch.com" target=3D"_blank">http://seanmiddleditch.com</a></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALQmNFhYbVgUdCb3OW6M6UoQmLYA8dLROGCR=
ZHN01fybB8-SRA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFhYbVgUdCb3=
OW6M6UoQmLYA8dLROGCRZHN01fybB8-SRA%40mail.gmail.com</a>.<br />

--001a1140e92e941585053d6b52c8--

.

--001a113ff0eeac5918053d6baca1
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 26, 2016 at 9:07 AM, Sean Middleditch <sean@middleditch.us>
wrote:

> On Sun, Sep 25, 2016 at 11:16 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>> *opt doesn't throw.
>>
>
> So it does not. Which is, arguably, worse. I mean, I staunchly dislike
> exceptions, but adding yet another unnecessary set of
> easy-to-accidentally-invoke UB is not great.
>

*opt should not throw since it is a precondition violation. Either you use
the throwing version when you don't know if it is engaged or not, in which
case you are using the exception for regular control flow (which is never
advocated), or you accidentally dereferenced the optional when it was
nullopt, in which case your program's invariants have been violated so you
shouldn't be trying to recover (you have a bug).

That said, I do I agree with you that what we have is not completely ideal
and is error prone. A "visit" or "match" can sometimes be better (though it
can be overkill, depending on who you talk to). I do have a solution that
should be in an upcoming paper if I complete it in time -- a revision of
p0376 (the std::call paper). The first version from the pre-Oulu mailing is
at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0376r0.html .
In the upcoming revision, the "active_field_of" provider has been renamed
"active_alternative_of" to be consistent with how variant refers to its
fields as "alternatives" and instead of dealing directly with just
std::variant, it and the other variant-related providers now deal with a
VariantLike concept that I introduce (not dependent on concepts TS, but
I'll try to make a concepts TS versions of the concept as well). Things
that can model VariantLike include std::variant, but also std::optional,
boost::variant, and the proposed std::expected. The implication here is
that you can do the equivalent of n-ary "visit" or "match", etc. in the
same way for variant, optional, expected, and others, along with several
other kinds of provisions that the revision introduces (I now have over 30
providers, though only a very small, core subset will be proposed).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dk6SmHDdp2Sq1ikQOOmVLodY9trHiDRgFQVghzzX2bug%40mail.gmail.com.

--001a113ff0eeac5918053d6baca1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Sep 26, 2016 at 9:07 AM, Sean Middleditch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Sun, S=
ep 25, 2016 at 11:16 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D=
"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><span><br>
</span>*opt doesn&#39;t throw.<br></blockquote><div><br></div><div>So it do=
es not. Which is, arguably, worse. I mean, I staunchly dislike exceptions, =
but adding yet another unnecessary set of easy-to-accidentally-invoke UB is=
 not great.</div></div></div></div></blockquote><div><br></div><div>*opt sh=
ould not throw since it is a precondition violation. Either you use the thr=
owing version when you don&#39;t know if it is engaged or not, in which cas=
e you are using the exception for regular control flow (which is never advo=
cated), or you accidentally dereferenced the optional when it was nullopt, =
in which case your program&#39;s invariants have been violated so you shoul=
dn&#39;t be trying to recover (you have a bug).</div><div><br></div><div>Th=
at said, I do I agree with you that what we have is not completely ideal an=
d is error prone. A &quot;visit&quot; or &quot;match&quot; can sometimes be=
 better (though it can be overkill, depending on who you talk to). I do hav=
e a solution that should be in an upcoming paper if I complete it in time -=
- a revision of p0376 (the std::call paper). The first version from the pre=
-Oulu mailing is at <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2016/p0376r0.html" target=3D"_blank">http://www.open-std.org/jtc1/<w=
br>sc22/wg21/docs/papers/2016/<wbr>p0376r0.html</a>=C2=A0. In the upcoming =
revision, the &quot;active_field_of&quot; provider has been renamed &quot;a=
ctive_alternative_of&quot; to be consistent with how variant refers to its =
fields as &quot;alternatives&quot; and instead of dealing directly with jus=
t std::variant, it and the other variant-related providers now deal with a =
VariantLike concept that I introduce (not dependent on concepts TS, but I&#=
39;ll try to make a concepts TS versions of the concept as well). Things th=
at can model VariantLike include std::variant, but also std::optional, boos=
t::variant, and the proposed std::expected. The implication here is that yo=
u can do the equivalent of n-ary &quot;visit&quot; or &quot;match&quot;, et=
c. in the same way for variant, optional, expected, and others, along with =
several other kinds of provisions that the revision introduces (I now have =
over 30 providers, though only a very small, core subset will be proposed).=
</div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dk6SmHDdp2Sq1ikQOOmVLodY9trH=
iDRgFQVghzzX2bug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3Dk6SmH=
Ddp2Sq1ikQOOmVLodY9trHiDRgFQVghzzX2bug%40mail.gmail.com</a>.<br />

--001a113ff0eeac5918053d6baca1--

.

On 26 September 2016 at 19:07, Sean Middleditch <sean@middleditch.us> wrote:
> On Sun, Sep 25, 2016 at 11:16 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>>
>> *opt doesn't throw.
>
>
> So it does not. Which is, arguably, worse. I mean, I staunchly dislike
> exceptions, but adding yet another unnecessary set of
> easy-to-accidentally-invoke UB is not great.

Right, it's not great, it's fantastic. If I do

if (opt) {
    opt->foo();
    opt->bar();
    f(*opt);
    g(*opt);
}

I don't expect the language to check every one of those indirections,
because I already checked them.

> Sadly, the committee/community wanted optional sooner rather than later,
> even if the language isn't ready to do it right yet, so here we are. :)

I doubt that definition of "right" is universally shared by everyone.

> Point stands. Easy-to-grep and safer-to-teach access to
> optional/variant/etc. is something that should be in the library. Since we'd

optional::value and optional::value_or don't cut it?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbJ2JhJj%2BC%2BO-pjH4jXxiB7%2BFeUoc9ubv9SmRAc7PpqnA%40mail.gmail.com.

.

--94eb2c05c36422eacc053d6ca59b
Content-Type: text/plain; charset=UTF-8

>
> Sadly, the committee/community wanted optional sooner rather than later,
> even if the language isn't ready to do it right yet, so here we are. :)
>

IMHO having a somewhat more error prone standard version is much better
than different people reinventing it on projects where using boost
libraries is forbidden for one reason or another other (I was in that
situation twice so it's not a theoretical reason).


> Point stands. Easy-to-grep and safer-to-teach access to
> optional/variant/etc. is something that should be in the library. Since
> we'd be targetting C++20 at a minimum, now, though, it's perhaps better to
> think about how any language features landing in that timeframe could
> potentially be used to make the access even better (because no, for-range
> abuse isn't great).
>

My point regarding abusing for range was that if alternative is not that
terrible compared to it (especially with if statements with initializers)
because in both cases I have to think what I'm doing but while reading
other people's code if won't confuse me while for will raise
aha-one-or-more flag in my head which has a greater potential of confusing
me and making the code harder to expand/modify.
That's why I think that standardizing iterators on optional would be a bad
idea since it would probably confuse far more people than it would make
interface less error prone. The interface isn't nearly as bad that we would
need alternatives at any cost.

Regards,
Domen

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ4pvEEC0GmA%3DVA82sxKA4aCL-uzOxt1_%3DfAbePq25uyw%40mail.gmail.com.

--94eb2c05c36422eacc053d6ca59b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Sadly, the committee/commu=
nity wanted optional sooner rather than later, even if the language isn&#39=
;t ready to do it right yet, so here we are. :)</div></div></div></div></bl=
ockquote><div><br></div><div>IMHO having a somewhat more error prone standa=
rd version is much better than different people reinventing it on projects =
where using boost libraries is forbidden for one reason or another other (I=
 was in that situation twice so it&#39;s not a theoretical reason).<br></di=
v><div>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Point=
 stands. Easy-to-grep and safer-to-teach access to optional/variant/etc. is=
 something that should be in the library. Since we&#39;d be targetting C++2=
0 at a minimum, now, though, it&#39;s perhaps better to think about how any=
 language features landing in that timeframe could potentially be used to m=
ake the access even better (because no, for-range abuse isn&#39;t great).</=
div></div></div></div></blockquote><div><br></div><div>My point regarding a=
busing for range was that if alternative is not that terrible compared to i=
t (especially with if statements with initializers) because in both cases I=
 have to think what I&#39;m doing but while reading other people&#39;s code=
 if won&#39;t confuse me while for will raise aha-one-or-more flag in my he=
ad which has a greater potential of confusing me and making the code harder=
 to expand/modify.<br></div><div>That&#39;s why I think that standardizing =
iterators on optional would be a bad idea since it would probably confuse f=
ar more people than it would make interface less error prone. The interface=
 isn&#39;t nearly as bad that we would need alternatives at any cost.<br><b=
r></div><div>Regards,<br></div><div>Domen<br></div></div></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ4pvEEC0GmA%3DVA82sxKA4aCL-uzO=
xt1_%3DfAbePq25uyw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BJ4pvEE=
C0GmA%3DVA82sxKA4aCL-uzOxt1_%3DfAbePq25uyw%40mail.gmail.com</a>.<br />

--94eb2c05c36422eacc053d6ca59b--

.

------=_Part_3366_436298346.1474915577450
Content-Type: multipart/alternative;
 boundary="----=_Part_3367_672827815.1474915577450"

------=_Part_3367_672827815.1474915577450
Content-Type: text/plain; charset=UTF-8

On Monday, September 26, 2016 at 1:42:03 PM UTC-4, Domen Vrankar wrote:
>
> Sadly, the committee/community wanted optional sooner rather than later,
>> even if the language isn't ready to do it right yet, so here we are. :)
>>
>
> IMHO having a somewhat more error prone standard version is much better
> than different people reinventing it on projects where using boost
> libraries is forbidden for one reason or another other (I was in that
> situation twice so it's not a theoretical reason).
>

Further, it really should be noted that `optional` as it stands is no *more*
error-prone than a pointer. So it's not like this tool is beyond the normal
stuff we have to deal with; it's just the same thing in a slightly
different form.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7f131b70-5a0b-455a-a4cd-7832ea133ad0%40isocpp.org.

------=_Part_3367_672827815.1474915577450
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 26, 2016 at 1:42:03 PM UTC-4, Domen V=
rankar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><blockquote style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_=
quote"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Sadly, the com=
mittee/community wanted optional sooner rather than later, even if the lang=
uage isn&#39;t ready to do it right yet, so here we are. :)</div></div></di=
v></div></blockquote><div><br></div><div>IMHO having a somewhat more error =
prone standard version is much better than different people reinventing it =
on projects where using boost libraries is forbidden for one reason or anot=
her other (I was in that situation twice so it&#39;s not a theoretical reas=
on).<br></div></div></div></div></blockquote><div><br>Further, it really sh=
ould be noted that `optional` as it stands is no <i>more</i> error-prone th=
an a pointer. So it&#39;s not like this tool is beyond the normal stuff we =
have to deal with; it&#39;s just the same thing in a slightly different for=
m.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7f131b70-5a0b-455a-a4cd-7832ea133ad0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f131b70-5a0b-455a-a4cd-7832ea133ad0=
%40isocpp.org</a>.<br />

------=_Part_3367_672827815.1474915577450--

------=_Part_3366_436298346.1474915577450--

.

------=_Part_5036_963868514.1474921155796
Content-Type: multipart/alternative;
 boundary="----=_Part_5037_1335450782.1474921155796"

------=_Part_5037_1335450782.1474921155796
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

How about...

std::optional<int> getOpt(int, int);

if (X& x : getOpt(137, 42))
    std::cout << x * 2;

... akin to range for? I.e., we could have ':' as the bind operation (in=20
monadic terms, not std::bind()), which binds getOpt()'s return value to the=
=20
body of the 'if'. (For those who don't know, I'm working extending=20
for-loops where we could use the same.)
The nice property of this syntax is that it works with pointers as well:

int a =3D 1;
int* pa =3D &a;

if (int& x : pa)
    std::cout << x * 2;


It way less error-prone than *pa or *opt_a, also it's got a simple syntax=
=20
and zero overhead. In fact, the  compiler it might optimize out the=20
optional itself much quicker than normally in this case (given it can=20
inline getOpt()) and convert getOpt()'s return statemens to return to a=20
given label in the caller, namely to 'if' and 'else' (given that type in=20
each return of getOpt() can be statically deduced to X or nullopt_t). Thus=
=20
it's both a syntax sugar and a hint for the optimizer.

What do you think?

Thanks,
-lorro

2016. szeptember 26., h=C3=A9tf=C5=91 20:46:17 UTC+2 id=C5=91pontban Nicol =
Bolas a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On Monday, September 26, 2016 at 1:42:03 PM UTC-4, Domen Vrankar wrote:
>>
>> Sadly, the committee/community wanted optional sooner rather than later,=
=20
>>> even if the language isn't ready to do it right yet, so here we are. :)
>>>
>>
>> IMHO having a somewhat more error prone standard version is much better=
=20
>> than different people reinventing it on projects where using boost=20
>> libraries is forbidden for one reason or another other (I was in that=20
>> situation twice so it's not a theoretical reason).
>>
>
> Further, it really should be noted that `optional` as it stands is no=20
> *more* error-prone than a pointer. So it's not like this tool is beyond=
=20
> the normal stuff we have to deal with; it's just the same thing in a=20
> slightly different form.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/e48dd1b8-7f29-4e41-a7a6-4f88750c4e3e%40isocpp.or=
g.

------=_Part_5037_1335450782.1474921155796
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>How about...<br><br><div class=3D"prettyprint" =
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=
 class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">optional</span><span style=3D"color: #080;" class=3D"s=
tyled-by-prettify">&lt;int&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> getOpt</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</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: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">X</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> getOpt</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">137</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">42</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> x </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: #066;" class=3D"styled-by-prettify">2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br>.. =
akin to range for? I.e., we could have &#39;:&#39; as the bind operation (i=
n monadic terms, not std::bind()), which binds getOpt()&#39;s return value =
to the body of the &#39;if&#39;. (For those who don&#39;t know, I&#39;m wor=
king extending for-loops where we could use the same.)<br>The nice property=
 of this syntax is that it works with pointers as well:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> pa </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> pa</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></code>=
</div><br>It way less error-prone than *pa or *opt_a, also it&#39;s got a s=
imple syntax and zero overhead. In fact, the=C2=A0 compiler it might optimi=
ze out the optional itself much quicker than normally in this case (given i=
t can inline getOpt()) and convert getOpt()&#39;s return statemens to retur=
n to a given label in the caller, namely to &#39;if&#39; and &#39;else&#39;=
 (given that type in each return of getOpt() can be statically deduced to X=
 or nullopt_t). Thus it&#39;s both a syntax sugar and a hint for the optimi=
zer.<br><br>What do you think?<br><br>Thanks,<br>-lorro<br><br>2016. szepte=
mber 26., h=C3=A9tf=C5=91 20:46:17 UTC+2 id=C5=91pontban Nicol Bolas a k=C3=
=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Monday, September 26, 2016 at 1:42:03 PM UTC-4, Domen Vran=
kar wrote:<blockquote 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><di=
v class=3D"gmail_quote"><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Sadly, the committee/c=
ommunity wanted optional sooner rather than later, even if the language isn=
&#39;t ready to do it right yet, so here we are. :)</div></div></div></div>=
</blockquote><div><br></div><div>IMHO having a somewhat more error prone st=
andard version is much better than different people reinventing it on proje=
cts where using boost libraries is forbidden for one reason or another othe=
r (I was in that situation twice so it&#39;s not a theoretical reason).<br>=
</div></div></div></div></blockquote><div><br>Further, it really should be =
noted that `optional` as it stands is no <i>more</i> error-prone than a poi=
nter. So it&#39;s not like this tool is beyond the normal stuff we have to =
deal with; it&#39;s just the same thing in a slightly different form.</div>=
</div></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e48dd1b8-7f29-4e41-a7a6-4f88750c4e3e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e48dd1b8-7f29-4e41-a7a6-4f88750c4e3e=
%40isocpp.org</a>.<br />

------=_Part_5037_1335450782.1474921155796--

------=_Part_5036_963868514.1474921155796--

.

--001a1144360252283d053d6f0f25
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 26, 2016 at 4:19 PM, <szollosi.lorand@gmail.com> wrote:

> Hi,
>
> How about...
>
> std::optional<int> getOpt(int, int);
>
> if (X& x : getOpt(137, 42))
>     std::cout << x * 2;
>
> .. akin to range for? I.e., we could have ':' as the bind operation (in
> monadic terms, not std::bind()), which binds getOpt()'s return value to the
> body of the 'if'. (For those who don't know, I'm working extending
> for-loops where we could use the same.)
> The nice property of this syntax is that it works with pointers as well:
>
> int a = 1;
> int* pa = &a;
>
> if (int& x : pa)
>     std::cout << x * 2;
>
>
> It way less error-prone than *pa or *opt_a, also it's got a simple syntax
> and zero overhead. In fact, the  compiler it might optimize out the
> optional itself much quicker than normally in this case (given it can
> inline getOpt()) and convert getOpt()'s return statemens to return to a
> given label in the caller, namely to 'if' and 'else' (given that type in
> each return of getOpt() can be statically deduced to X or nullopt_t). Thus
> it's both a syntax sugar and a hint for the optimizer.
>
> What do you think?
>

+1
I was thinking about this, and heading in exactly the same direction.



>
> Thanks,
> -lorro
>


--
Be seeing you,
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu08ArXW_jqfwbLUfNDRGkQ6pXVhvoAwoQ7De5zbMi2Ug%40mail.gmail.com.

--001a1144360252283d053d6f0f25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Sep 26, 2016 at 4:19 PM,  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:szollosi.lorand@gmail.com" target=3D"_blank">szollosi.lorand@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,=
<br><br>How about...<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wra=
p:break-word"><code><div><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">optional</span><span st=
yle=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#000"> getOpt</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#008">int</span><span style=3D"color:#660">);</span><span s=
tyle=3D"color:#000"><br><br></span><span style=3D"color:#008">if</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">X</span><span style=3D"color:#660">&amp;</span><span styl=
e=3D"color:#000"> x </span><span style=3D"color:#660">:</span><span style=
=3D"color:#000"> getOpt</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#066">137</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#066">42</span><span style=3D"=
color:#660">))</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 std</span=
><span style=3D"color:#660">::</span><span style=3D"color:#000">cout </span=
><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#000"> x </=
span><span style=3D"color:#660">*</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#066">2</span><span style=3D"color:#660">;</span><span=
 style=3D"color:#000"><br></span></div></code></div><br>.. akin to range fo=
r? I.e., we could have &#39;:&#39; as the bind operation (in monadic terms,=
 not std::bind()), which binds getOpt()&#39;s return value to the body of t=
he &#39;if&#39;. (For those who don&#39;t know, I&#39;m working extending f=
or-loops where we could use the same.)<br>The nice property of this syntax =
is that it works with pointers as well:<br><br><div style=3D"background-col=
or: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"color:#000"> a </span><span style=3D"color:#660">=3D</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">1</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><s=
pan style=3D"color:#008">int</span><span style=3D"color:#660">*</span><span=
 style=3D"color:#000"> pa </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span><span =
style=3D"color:#000">a</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span><span style=3D"color:#008">if</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">int</span><span style=3D"color:#660">&amp;</span><span styl=
e=3D"color:#000"> x </span><span style=3D"color:#660">:</span><span style=
=3D"color:#000"> pa</span><span style=3D"color:#660">)</span><span style=3D=
"color:#000"><br>=C2=A0 =C2=A0 std</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#000">cout </span><span style=3D"color:#660">&lt;&lt=
;</span><span style=3D"color:#000"> x </span><span style=3D"color:#660">*</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">2</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"><br><br></spa=
n></div></code></div><br>It way less error-prone than *pa or *opt_a, also i=
t&#39;s got a simple syntax and zero overhead. In fact, the=C2=A0 compiler =
it might optimize out the optional itself much quicker than normally in thi=
s case (given it can inline getOpt()) and convert getOpt()&#39;s return sta=
temens to return to a given label in the caller, namely to &#39;if&#39; and=
 &#39;else&#39; (given that type in each return of getOpt() can be statical=
ly deduced to X or nullopt_t). Thus it&#39;s both a syntax sugar and a hint=
 for the optimizer.<br><br>What do you think?<br></div></blockquote><div><b=
r>+1<br></div><div>I was thinking about this, and heading in exactly the sa=
me direction.<br><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><br>Thanks,<br>-lorro<span class=3D""></span><br></div></blockquo=
te></div><br clear=3D"all"><br>-- <br><div class=3D"gmail_signature" data-s=
martmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing you,<br></div>=
Tony<br></div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu08ArXW_jqfwbLUfNDRGkQ6pXVhvoA=
woQ7De5zbMi2Ug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiu08ArXW_jq=
fwbLUfNDRGkQ6pXVhvoAwoQ7De5zbMi2Ug%40mail.gmail.com</a>.<br />

--001a1144360252283d053d6f0f25--

.

On 26 September 2016 at 23:34, Tony V E <tvaneerd@gmail.com> wrote:
>
>
> On Mon, Sep 26, 2016 at 4:19 PM, <szollosi.lorand@gmail.com> wrote:
>>
>> Hi,
>>
>> How about...
>>
>> std::optional<int> getOpt(int, int);
>>
>> if (X& x : getOpt(137, 42))
>>     std::cout << x * 2;
>>
>> .. akin to range for? I.e., we could have ':' as the bind operation (in
>> monadic terms, not std::bind()), which binds getOpt()'s return value to the
>> body of the 'if'. (For those who don't know, I'm working extending for-loops
>> where we could use the same.)
>> The nice property of this syntax is that it works with pointers as well:
>>
>> int a = 1;
>> int* pa = &a;
>>
>> if (int& x : pa)
>>     std::cout << x * 2;
>>
>>
>> It way less error-prone than *pa or *opt_a, also it's got a simple syntax
>> and zero overhead. In fact, the  compiler it might optimize out the optional
>> itself much quicker than normally in this case (given it can inline
>> getOpt()) and convert getOpt()'s return statemens to return to a given label
>> in the caller, namely to 'if' and 'else' (given that type in each return of
>> getOpt() can be statically deduced to X or nullopt_t). Thus it's both a
>> syntax sugar and a hint for the optimizer.
>>
>> What do you think?
>
>
> +1
> I was thinking about this, and heading in exactly the same direction.


Way ahead of you:
https://cplusplus.github.io/EWG/ewg-closed.html#140

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaWST8tum4FezBUZ4rMjwbcUNHEo9QZp9_Aq_CS_EgAAQ%40mail.gmail.com.

.

------=_Part_5030_861835743.1474923559546
Content-Type: multipart/alternative;
 boundary="----=_Part_5031_1380694888.1474923559546"

------=_Part_5031_1380694888.1474923559546
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

'EWG found the motivation for the proposal insufficient.' - why oh why...
(sometimes I feel we needed random macro parameter separators like ':', ';'=
=20
beside ',', just to be able to implement these dropped features).

-lorro

2016. szeptember 26., h=C3=A9tf=C5=91 22:43:06 UTC+2 id=C5=91pontban Ville =
Voutilainen a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On 26 September 2016 at 23:34, Tony V E <tvan...@gmail.com <javascript:>>=
=20
> wrote:=20
> >=20
> >=20
> > On Mon, Sep 26, 2016 at 4:19 PM, <szollos...@gmail.com <javascript:>>=
=20
> wrote:=20
> >>=20
> >> Hi,=20
> >>=20
> >> How about...=20
> >>=20
> >> std::optional<int> getOpt(int, int);=20
> >>=20
> >> if (X& x : getOpt(137, 42))=20
> >>     std::cout << x * 2;=20
> >>=20
> >> .. akin to range for? I.e., we could have ':' as the bind operation (i=
n=20
> >> monadic terms, not std::bind()), which binds getOpt()'s return value t=
o=20
> the=20
> >> body of the 'if'. (For those who don't know, I'm working extending=20
> for-loops=20
> >> where we could use the same.)=20
> >> The nice property of this syntax is that it works with pointers as=20
> well:=20
> >>=20
> >> int a =3D 1;=20
> >> int* pa =3D &a;=20
> >>=20
> >> if (int& x : pa)=20
> >>     std::cout << x * 2;=20
> >>=20
> >>=20
> >> It way less error-prone than *pa or *opt_a, also it's got a simple=20
> syntax=20
> >> and zero overhead. In fact, the  compiler it might optimize out the=20
> optional=20
> >> itself much quicker than normally in this case (given it can inline=20
> >> getOpt()) and convert getOpt()'s return statemens to return to a given=
=20
> label=20
> >> in the caller, namely to 'if' and 'else' (given that type in each=20
> return of=20
> >> getOpt() can be statically deduced to X or nullopt_t). Thus it's both =
a=20
> >> syntax sugar and a hint for the optimizer.=20
> >>=20
> >> What do you think?=20
> >=20
> >=20
> > +1=20
> > I was thinking about this, and heading in exactly the same direction.=
=20
>
>
> Way ahead of you:=20
> https://cplusplus.github.io/EWG/ewg-closed.html#140=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/90f87390-7f0d-4d33-a852-247f907ad297%40isocpp.or=
g.

------=_Part_5031_1380694888.1474923559546
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>&#39;EWG found the motivation for the proposal =
insufficient.&#39; - why oh why...<br>(sometimes I feel we needed random ma=
cro parameter separators like &#39;:&#39;, &#39;;&#39; beside &#39;,&#39;, =
just to be able to implement these dropped features).<br><br>-lorro<br><br>=
2016. szeptember 26., h=C3=A9tf=C5=91 22:43:06 UTC+2 id=C5=91pontban Ville =
Voutilainen a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On 26 September 2016 at 23:34, Tony V E &lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FhF5UdPKBAAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a>=
&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Mon, Sep 26, 2016 at 4:19 PM, &lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"FhF5UdPKBAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">szollos...@gmail.com</a>&gt; wrote=
:
<br>&gt;&gt;
<br>&gt;&gt; Hi,
<br>&gt;&gt;
<br>&gt;&gt; How about...
<br>&gt;&gt;
<br>&gt;&gt; std::optional&lt;int&gt; getOpt(int, int);
<br>&gt;&gt;
<br>&gt;&gt; if (X&amp; x : getOpt(137, 42))
<br>&gt;&gt; =C2=A0 =C2=A0 std::cout &lt;&lt; x * 2;
<br>&gt;&gt;
<br>&gt;&gt; .. akin to range for? I.e., we could have &#39;:&#39; as the b=
ind operation (in
<br>&gt;&gt; monadic terms, not std::bind()), which binds getOpt()&#39;s re=
turn value to the
<br>&gt;&gt; body of the &#39;if&#39;. (For those who don&#39;t know, I&#39=
;m working extending for-loops
<br>&gt;&gt; where we could use the same.)
<br>&gt;&gt; The nice property of this syntax is that it works with pointer=
s as well:
<br>&gt;&gt;
<br>&gt;&gt; int a =3D 1;
<br>&gt;&gt; int* pa =3D &amp;a;
<br>&gt;&gt;
<br>&gt;&gt; if (int&amp; x : pa)
<br>&gt;&gt; =C2=A0 =C2=A0 std::cout &lt;&lt; x * 2;
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; It way less error-prone than *pa or *opt_a, also it&#39;s got =
a simple syntax
<br>&gt;&gt; and zero overhead. In fact, the =C2=A0compiler it might optimi=
ze out the optional
<br>&gt;&gt; itself much quicker than normally in this case (given it can i=
nline
<br>&gt;&gt; getOpt()) and convert getOpt()&#39;s return statemens to retur=
n to a given label
<br>&gt;&gt; in the caller, namely to &#39;if&#39; and &#39;else&#39; (give=
n that type in each return of
<br>&gt;&gt; getOpt() can be statically deduced to X or nullopt_t). Thus it=
&#39;s both a
<br>&gt;&gt; syntax sugar and a hint for the optimizer.
<br>&gt;&gt;
<br>&gt;&gt; What do you think?
<br>&gt;
<br>&gt;
<br>&gt; +1
<br>&gt; I was thinking about this, and heading in exactly the same directi=
on.
<br>
<br>
<br>Way ahead of you:
<br><a href=3D"https://cplusplus.github.io/EWG/ewg-closed.html#140" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-closed.html=
%23140\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFzlz0SvJ0FsKCHxZ5oC2HEV7gNXw=
&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?=
q\x3dhttps%3A%2F%2Fcplusplus.github.io%2FEWG%2Fewg-closed.html%23140\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFzlz0SvJ0FsKCHxZ5oC2HEV7gNXw&#39;;return =
true;">https://cplusplus.github.io/<wbr>EWG/ewg-closed.html#140</a>
<br></blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90f87390-7f0d-4d33-a852-247f907ad297%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90f87390-7f0d-4d33-a852-247f907ad297=
%40isocpp.org</a>.<br />

------=_Part_5031_1380694888.1474923559546--

------=_Part_5030_861835743.1474923559546--

.

--94eb2c123cb440fa9d053d6fc3cf
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 26, 2016 at 1:59 PM, <szollosi.lorand@gmail.com> wrote:

> Hi,
>
> 'EWG found the motivation for the proposal insufficient.' - why oh why...
>

Read the paper. It's arguably a very weak presentation of the FP
fundamentals necessary to understand the use cases.

At this point, a one-off syntax that does nothing more than
checked-assignment is pretty uninteresting. Structured bindings at the very
least needs to be taken into account and how that would extend to full-on
pattern matching.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFhvpKC1w9WaKQS43-04r7PV_kYRQBh_gxBSGjYzssCcrQ%40mail.gmail.com.

--94eb2c123cb440fa9d053d6fc3cf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Sep 26, 2016 at 1:59 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:szoll=
osi.lorand@gmail.com" target=3D"_blank">szollosi.lorand@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>=
&#39;EWG found the motivation for the proposal insufficient.&#39; - why oh =
why...<br></div></blockquote><div><br></div><div>Read the paper. It&#39;s a=
rguably a very weak presentation of the FP fundamentals necessary to unders=
tand the use cases.<br></div><div><br></div><div>At this point, a one-off s=
yntax that does nothing more than checked-assignment is pretty uninterestin=
g. Structured bindings at the very least needs to be taken into account and=
 how that would extend to full-on pattern matching.</div></div>
</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALQmNFhvpKC1w9WaKQS43-04r7PV_kYRQBh_=
gxBSGjYzssCcrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFhvpKC1w9Wa=
KQS43-04r7PV_kYRQBh_gxBSGjYzssCcrQ%40mail.gmail.com</a>.<br />

--94eb2c123cb440fa9d053d6fc3cf--

.

On 27 September 2016 at 00:25, Sean Middleditch <sean@middleditch.us> wrote:
> On Mon, Sep 26, 2016 at 1:59 PM, <szollosi.lorand@gmail.com> wrote:
>>
>> Hi,
>>
>> 'EWG found the motivation for the proposal insufficient.' - why oh why...
>
>
> Read the paper. It's arguably a very weak presentation of the FP
> fundamentals necessary to understand the use cases.
>
> At this point, a one-off syntax that does nothing more than
> checked-assignment is pretty uninteresting. Structured bindings at the very
> least needs to be taken into account and how that would extend to full-on
> pattern matching.


Which is indeed one of the reasons why EWG found that proposal
unconvincing. If we want
pattern matching, perhaps we should go for pattern matching rather
than minor tweaks to
tiny facilities of the language, like an if-statement.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZk5fEf-yAfEaY%3DmDkDYaffYkD4-6y6tMEb1%2BZAEowv-A%40mail.gmail.com.

.

------=_Part_5202_1709334684.1474927652636
Content-Type: multipart/alternative;
 boundary="----=_Part_5203_81651990.1474927652636"

------=_Part_5203_81651990.1474927652636
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

You're right that it can probably be presented better; however, I don't=20
think it's an FP/non-FP question. Quite the contrary: it's a perfect little=
=20
tool when porting tons of legacy code where you 'just know' when you can=20
dereference a nullptr or when an object can / can't be in invalid state.=20
And I guess it's a very common problem.
(BTW, to me the 'perfect' optional would have a visitor with an optional=20
else; but ymmw and I understand you can't force it on everyone).

Thanks,
-lorro

2016. szeptember 26., h=C3=A9tf=C5=91 23:25:11 UTC+2 id=C5=91pontban Sean M=
iddleditch a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On Mon, Sep 26, 2016 at 1:59 PM, <szollos...@gmail.com <javascript:>>=20
> wrote:
>
>> Hi,
>>
>> 'EWG found the motivation for the proposal insufficient.' - why oh why..=
..
>>
>
> Read the paper. It's arguably a very weak presentation of the FP=20
> fundamentals necessary to understand the use cases.
>
> At this point, a one-off syntax that does nothing more than=20
> checked-assignment is pretty uninteresting. Structured bindings at the ve=
ry=20
> least needs to be taken into account and how that would extend to full-on=
=20
> pattern matching.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7eddf09b-6df8-4fb5-9d48-fef5eeee1e8f%40isocpp.or=
g.

------=_Part_5203_81651990.1474927652636
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>You&#39;re right that it can probably be presen=
ted better; however, I don&#39;t think it&#39;s an FP/non-FP question. Quit=
e the contrary: it&#39;s a perfect little tool when porting tons of legacy =
code where you &#39;just know&#39; when you can dereference a nullptr or wh=
en an object can / can&#39;t be in invalid state. And I guess it&#39;s a ve=
ry common problem.<br>(BTW, to me the &#39;perfect&#39; optional would have=
 a visitor with an optional else; but ymmw and I understand you can&#39;t f=
orce it on everyone).<br><br>Thanks,<br>-lorro<br><br>2016. szeptember 26.,=
 h=C3=A9tf=C5=91 23:25:11 UTC+2 id=C5=91pontban Sean Middleditch a k=C3=B6v=
etkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote">On Mon, Sep 26, 2016 at 1:59 PM, =
 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"oqPyNR_NBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">szollos...@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">Hi,<br><br>&#39;EWG found the motivati=
on for the proposal insufficient.&#39; - why oh why...<br></div></blockquot=
e><div><br></div><div>Read the paper. It&#39;s arguably a very weak present=
ation of the FP fundamentals necessary to understand the use cases.<br></di=
v><div><br></div><div>At this point, a one-off syntax that does nothing mor=
e than checked-assignment is pretty uninteresting. Structured bindings at t=
he very least needs to be taken into account and how that would extend to f=
ull-on pattern matching.</div></div>
</div></div>
</blockquote></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7eddf09b-6df8-4fb5-9d48-fef5eeee1e8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7eddf09b-6df8-4fb5-9d48-fef5eeee1e8f=
%40isocpp.org</a>.<br />

------=_Part_5203_81651990.1474927652636--

------=_Part_5202_1709334684.1474927652636--

.