On 23 April 2017 at 00:23, David Peterson <djpeterson83@hotmail.com> wrote:
> // New way with `if` auto-dereferencing language feature //
> if (auto& customer : get_customer(customer_id)) {
>     process(customer); // customer is a Customer& and not an optional.
>                        // We can safely use customer as we are guaranteed
>                        // to have a valid reference and that reference
>                        // cannot extend beyond the `if` scope
> }
> else {
>     show_customer_not_found();
> }
>
> As you can see, this feature is readable and addresses the indirection
> problem from earlier.  Furthermore, it can be optimized easier for optional
> types and can theoretically work with any type, including user types, so
> long as they provide a conversion to boolean operator and a dereference
> operator.  An example of how this could be interpreted follows:
>
> // New feature translates into... //
> auto _optional_customer = get_customer(customer_id);
> if (_optional_customer) {
>     auto& customer = *_optional_customer;
>     process(customer);
> }
> else {
>     show_customer_not_found();
> }
>
> I'm sure language features are not the easiest thing to add, and I'm no
> compiler developer, but I'm anxious to hear any feedback you may have in
> regards to short comings, enhancements and overall complexity to implement.
> Thank you for considering this feature. - David Peterson


This seems to be essentially suggesting what was proposed in
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4127.html,
and that paper failed to gain consensus.

--
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/CAFk2RUaOQ6v_rT2n2pPz1EOCJtY7mXeRiz1iTG7_P_gBf5H2Bg%40mail.gmail.com.

.

On Sat, Apr 22, 2017 at 2:23 PM, David Peterson
<djpeterson83@hotmail.com> wrote:
> // Example of an optional as if it were a container of one or zero items //
> for (auto& customer : get_customer(customer_id)) {
>     process(customer);
> }
>
> Obviously, this syntax is a bit awkward.  It just doesn't make sense to
> consider an optional as a container.  Furthermore, there would likely be a
> high degree of unnecessary overhead in interpreting the optional as a
> container.  Iterators would also have to be made to support the begin/end
> range.

Not quite, given the relaxed range-for, `end` can be
as simple as a sentinel with a different type, such as
nullopt or some equivalents.  But, after I tried to
implement these in various ways, I found that, indeed,
both gcc and clang have difficulties optimizing this
construct into non-loops.  However, I expect these
problems to be overcame by special casing some
particulate patterns in front-ends.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent 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/CAGsORuAffyURPXf0wXsRKgts5JqmXjoWG4zCbmg%3D_dJjmL8hwQ%40mail.gmail.com.

.

------=_Part_1298_1294830129.1492902556483
Content-Type: multipart/alternative;
 boundary="----=_Part_1299_2040347097.1492902556483"

------=_Part_1299_2040347097.1492902556483
Content-Type: text/plain; charset=UTF-8

Thanks for the feedback.  I'm new to this so didn't realize someone beat me
to it.  Though I'm more of a hobbyist with C++ in general, I've worked with
optionals in the past in other languages in a much more professional
context.  I've found proper implementation and ease of use of optionals can
seriously increase the stability of a project, especially when newer
members are introduced to the development team.  I would consider this my
vote towards the aforementioned proposal.

@Zhihao Yuan, it's good to know that some optimization can occur inside my
ranged for-loop example.  I still find its usage awkward for optionals, and
I too have built an implementation around this.  It also doesn't address
the `else` clause which I feel is very much needed.

I did find out with some serious macro *abuse *that a very close copy of
this functionality can exist.  I *wouldn't recommend this in production
code*, of course:

// Badness ensues...
#define if_has(a, b) if(b) for (a : {*b})

..
..
..

if_has(auto& customer, get_customer(customer_id)) {
    process(customer);
}
else {
    show_customer_not_found();
}

Since there doesn't seem to be much of a draw for this kind of feature
natively, I'll just patiently wait in the hopes that more support comes to
pass.  Thanks again for your review!

--
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/7637ff36-78e8-4166-8b26-ad474c1d1034%40isocpp.org.

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

<div dir=3D"ltr">Thanks for the feedback. =C2=A0I&#39;m new to this so didn=
&#39;t realize someone beat me to it. =C2=A0Though I&#39;m more of a hobbyi=
st with C++ in general, I&#39;ve worked with optionals in the past in other=
 languages in a much more professional context. =C2=A0I&#39;ve found proper=
 implementation and ease of use of optionals can seriously increase the sta=
bility of a project, especially when newer members are introduced to the de=
velopment team. =C2=A0I would consider this my vote towards the aforementio=
ned proposal.<div><br></div><div>@Zhihao Yuan, it&#39;s good to know that s=
ome optimization can occur inside my ranged for-loop example. =C2=A0I still=
 find its usage awkward for optionals, and I too have built an implementati=
on around this. =C2=A0It also doesn&#39;t address the `else` clause which I=
 feel is very much needed.</div><div><br></div><div>I did find out with som=
e serious macro <b>abuse </b>that a very close copy of this functionality c=
an exist. =C2=A0I <b>wouldn&#39;t recommend this in production code</b>, of=
 course:</div><div><br></div><div><div style=3D"color: rgb(212, 212, 212); =
background-color: rgb(30, 30, 30); font-family: Consolas, &quot;Courier New=
&quot;, monospace; font-size: 14px; line-height: 19px;"><div><span style=3D=
"color: #608b4e;">//=C2=A0Badness=C2=A0ensues...</span></div><div><span sty=
le=3D"color: #c586c0;">#define</span><span style=3D"color: #569cd6;">=C2=A0=
</span><span style=3D"color: #dcdcaa;">if_has</span><span style=3D"color: #=
569cd6;">(</span><span style=3D"color: #9cdcfe;">a,=C2=A0b</span><span styl=
e=3D"color: #569cd6;">)=C2=A0</span><span style=3D"color: #c586c0;">if</spa=
n><span style=3D"color: #569cd6;">(b)=C2=A0</span><span style=3D"color: #c5=
86c0;">for</span><span style=3D"color: #569cd6;">=C2=A0(a=C2=A0:=C2=A0{</sp=
an>*<span style=3D"color: #569cd6;">b})</span></div><br><div>.</div><div>.<=
/div><div>.</div><br><div><span style=3D"color: #dcdcaa;">if_has</span>(<sp=
an style=3D"color: #569cd6;">auto</span>&amp;=C2=A0customer,=C2=A0get_custo=
mer(customer_id))=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"c=
olor: #dcdcaa;">process</span>(customer);</div><div>}</div><div><span style=
=3D"color: #c586c0;">else</span>=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<=
span style=3D"color: #dcdcaa;">show_customer_not_found</span>();</div><div>=
}</div></div></div><div><br></div><div>Since there doesn&#39;t seem to be m=
uch of a draw for this kind of feature natively, I&#39;ll just patiently wa=
it in the hopes that more support comes to pass. =C2=A0Thanks again for you=
r review!</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/7637ff36-78e8-4166-8b26-ad474c1d1034%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7637ff36-78e8-4166-8b26-ad474c1d1034=
%40isocpp.org</a>.<br />

------=_Part_1299_2040347097.1492902556483--

------=_Part_1298_1294830129.1492902556483--

.

------=_Part_1170_1198948715.1492915819657
Content-Type: multipart/alternative;
 boundary="----=_Part_1171_2018060283.1492915819657"

------=_Part_1171_2018060283.1492915819657
Content-Type: text/plain; charset=UTF-8

Transforming the optional into a contiguous range seems to optimize well
(https://godbolt.org/g/RUfWZK):

template<class O>
class optional_range {
    O o_;
public:
    optional_range() = default;
    template<class Arg>
    optional_range(Arg&& a) : o_{std::forward<Arg>(a)} {}

    auto data() {
        return o_ ? std::addressof(*o_) : nullptr;
    }
    auto data() const {
        return o_ ? std::addressof(*o_) : nullptr;
    }
    bool empty() const { return !o_; }
    std::size_t size() const { return !empty(); }
    auto begin() { return data(); }
    auto end() { return data() + size(); }
    auto begin() const { return data(); }
    auto end() const { return data() + size(); }
};

template<class T>
optional_range(std::optional<T>&&) -> optional_range<std::optional<T>>;

template<class T>
optional_range(std::optional<T>&) -> optional_range<std::optional<T>&>;

template<class T>
optional_range(std::optional<T> const&) -> optional_range<std::optional<T>
const&>;

template<class T>
optional_range(std::optional<T> const&&) ->
optional_range<std::optional<T>>;


This approach could be easily standardized as an explicit conversion from
optional<T> to span<T>.

On Saturday, April 22, 2017 at 3:25:16 PM UTC-7, Zhihao Yuan wrote:
>
> On Sat, Apr 22, 2017 at 2:23 PM, David Peterson
> <djpete...@hotmail.com <javascript:>> wrote:
> > // Example of an optional as if it were a container of one or zero items
> //
> > for (auto& customer : get_customer(customer_id)) {
> >     process(customer);
> > }
> >
> > Obviously, this syntax is a bit awkward.  It just doesn't make sense to
> > consider an optional as a container.  Furthermore, there would likely be
> a
> > high degree of unnecessary overhead in interpreting the optional as a
> > container.  Iterators would also have to be made to support the
> begin/end
> > range.
>
> Not quite, given the relaxed range-for, `end` can be
> as simple as a sentinel with a different type, such as
> nullopt or some equivalents.  But, after I tried to
> implement these in various ways, I found that, indeed,
> both gcc and clang have difficulties optimizing this
> construct into non-loops.  However, I expect these
> problems to be overcame by special casing some
> particulate patterns in front-ends.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent 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/74399e77-18a2-460d-8bac-dae9bbce55d8%40isocpp.org.

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

<div dir=3D"ltr">Transforming the optional into a contiguous range seems to=
 optimize well (https://godbolt.org/g/RUfWZK):<div><br></div><blockquote st=
yle=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><font fac=
e=3D"courier new, monospace">template&lt;class O&gt;</font></div></div><div=
><div><font face=3D"courier new, monospace">class optional_range {</font></=
div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 O o=
_;</font></div></div><div><div><font face=3D"courier new, monospace">public=
:</font></div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 optional_range() =3D default;</font></div></div><div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 template&lt;class Arg&gt;</font><=
/div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 op=
tional_range(Arg&amp;&amp; a) : o_{std::forward&lt;Arg&gt;(a)} {}</font></d=
iv></div><div><div><font face=3D"courier new, monospace"><br></font></div><=
/div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 auto dat=
a() {</font></div></div><div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 return o_ ? std::addressof(*o_) : nullptr;</font><=
/div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }<=
/font></div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 auto data() const {</font></div></div><div><div><font face=3D"courie=
r new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 return o_ ? std::addressof(*o=
_) : nullptr;</font></div></div><div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 }</font></div></div><div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 bool empty() const { return !o_; }</font></div></=
div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 std::size=
_t size() const { return !empty(); }</font></div></div><div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 auto begin() { return data(); }</=
font></div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 auto end() { return data() + size(); }</font></div></div><div><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 auto begin() const { return=
 data(); }</font></div></div><div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 auto end() const { return data() + size(); }</font></div></=
div><div><div><font face=3D"courier new, monospace">};</font></div></div><d=
iv><div><font face=3D"courier new, monospace"><br></font></div></div><div><=
div><font face=3D"courier new, monospace">template&lt;class T&gt;</font></d=
iv></div><div><div><font face=3D"courier new, monospace">optional_range(std=
::optional&lt;T&gt;&amp;&amp;) -&gt; optional_range&lt;std::optional&lt;T&g=
t;&gt;;</font></div></div><div><div><font face=3D"courier new, monospace"><=
br></font></div></div><div><div><font face=3D"courier new, monospace">templ=
ate&lt;class T&gt;</font></div></div><div><div><font face=3D"courier new, m=
onospace">optional_range(std::optional&lt;T&gt;&amp;) -&gt; optional_range&=
lt;std::optional&lt;T&gt;&amp;&gt;;</font></div></div><div><div><font face=
=3D"courier new, monospace"><br></font></div></div><div><div><font face=3D"=
courier new, monospace">template&lt;class T&gt;</font></div></div><div><div=
><font face=3D"courier new, monospace">optional_range(std::optional&lt;T&gt=
; const&amp;) -&gt; optional_range&lt;std::optional&lt;T&gt; const&amp;&gt;=
;</font></div></div><div><div><font face=3D"courier new, monospace"><br></f=
ont></div></div><div><div><font face=3D"courier new, monospace">template&lt=
;class T&gt;</font></div></div><div><div><font face=3D"courier new, monospa=
ce">optional_range(std::optional&lt;T&gt; const&amp;&amp;) -&gt; optional_r=
ange&lt;std::optional&lt;T&gt;&gt;;</font></div></div></blockquote><div><di=
v><br></div><div>This approach could be easily standardized as an explicit =
conversion from optional&lt;T&gt; to span&lt;T&gt;.</div><br>On Saturday, A=
pril 22, 2017 at 3:25:16 PM UTC-7, Zhihao Yuan wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">On Sat, Apr 22, 2017 at 2:23 PM, David Peterson
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jKDO44yUDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">djpete...@hotmail.com</a>&gt; wrote:
<br>&gt; // Example of an optional as if it were a container of one or zero=
 items //
<br>&gt; for (auto&amp; customer : get_customer(customer_id)) {
<br>&gt; =C2=A0 =C2=A0 process(customer);
<br>&gt; }
<br>&gt;
<br>&gt; Obviously, this syntax is a bit awkward. =C2=A0It just doesn&#39;t=
 make sense to
<br>&gt; consider an optional as a container. =C2=A0Furthermore, there woul=
d likely be a
<br>&gt; high degree of unnecessary overhead in interpreting the optional a=
s a
<br>&gt; container. =C2=A0Iterators would also have to be made to support t=
he begin/end
<br>&gt; range.
<br>
<br>Not quite, given the relaxed range-for, `end` can be
<br>as simple as a sentinel with a different type, such as
<br>nullopt or some equivalents. =C2=A0But, after I tried to
<br>implement these in various ways, I found that, indeed,
<br>both gcc and clang have difficulties optimizing this
<br>construct into non-loops. =C2=A0However, I expect these
<br>problems to be overcame by special casing some
<br>particulate patterns in front-ends.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_________________
<br></blockquote></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/74399e77-18a2-460d-8bac-dae9bbce55d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/74399e77-18a2-460d-8bac-dae9bbce55d8=
%40isocpp.org</a>.<br />

------=_Part_1171_2018060283.1492915819657--

------=_Part_1170_1198948715.1492915819657--

.

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

On Sat, Apr 22, 2017 at 10:50 PM, Casey Carter <cartec69@gmail.com> wrote:

> Transforming the optional into a contiguous range seems to optimize well =
(
> https://godbolt.org/g/RUfWZK):
>
> template<class O>
> class optional_range {
>     O o_;
> public:
>     optional_range() =3D default;
>     template<class Arg>
>     optional_range(Arg&& a) : o_{std::forward<Arg>(a)} {}
>
>     auto data() {
>         return o_ ? std::addressof(*o_) : nullptr;
>     }
>     auto data() const {
>         return o_ ? std::addressof(*o_) : nullptr;
>     }
>     bool empty() const { return !o_; }
>     std::size_t size() const { return !empty(); }
>     auto begin() { return data(); }
>     auto end() { return data() + size(); }
>     auto begin() const { return data(); }
>     auto end() const { return data() + size(); }
> };
>
> template<class T>
> optional_range(std::optional<T>&&) -> optional_range<std::optional<T>>;
>
> template<class T>
> optional_range(std::optional<T>&) -> optional_range<std::optional<T>&>;
>
> template<class T>
> optional_range(std::optional<T> const&) -> optional_range<std::optional<T=
>
> const&>;
>
> template<class T>
> optional_range(std::optional<T> const&&) -> optional_range<std::optional<
> T>>;
>
>
> This approach could be easily standardized as an explicit conversion from
> optional<T> to span<T>.
>

"Your scientists were so preoccupied with whether or not they could, they
didn=E2=80=99t stop to think if they should."
- Dr. Ian Malcolm (Jurassic Park)

We could make optional into a range, but is it really a good idea? I doubt
it.
We could also make any object a range of size 1, for example.

--=20
Be seeing you,
Tony

--=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/CAOHCbitiBfiQq%2ByzrR6eHtWGLu5b3C7MZ%3DAwk-Sug4S=
yyZOaxA%40mail.gmail.com.

--f403045f155e60f59d054dcd692e
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 Sat, Apr 22, 2017 at 10:50 PM, Casey Carter <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr">Transforming the optional into a contiguous range seems to o=
ptimize well (<a href=3D"https://godbolt.org/g/RUfWZK" target=3D"_blank">ht=
tps://godbolt.org/g/RUfWZK</a>)<wbr>:<div><br></div><blockquote style=3D"ma=
rgin:0px 0px 0px 40px;border-width:medium;border-style:none;border-color:cu=
rrentcolor;padding:0px"><div><div><font face=3D"courier new, monospace">tem=
plate&lt;class O&gt;</font></div></div><div><div><font face=3D"courier new,=
 monospace">class optional_range {</font></div></div><div><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 O o_;</font></div></div><div><div=
><font face=3D"courier new, monospace">public:</font></div></div><div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 optional_range() =3D de=
fault;</font></div></div><div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 template&lt;class Arg&gt;</font></div></div><div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 optional_range(Arg&amp;&amp; a=
) : o_{std::forward&lt;Arg&gt;(a)} {}</font></div></div><div><div><font fac=
e=3D"courier new, monospace"><br></font></div></div><div><div><font face=3D=
"courier new, monospace">=C2=A0 =C2=A0 auto data() {</font></div></div><div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret=
urn o_ ? std::addressof(*o_) : nullptr;</font></div></div><div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 }</font></div></div><div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 auto data() const {</fo=
nt></div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 return o_ ? std::addressof(*o_) : nullptr;</font></div></=
div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 }</font><=
/div></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 bo=
ol empty() const { return !o_; }</font></div></div><div><div><font face=3D"=
courier new, monospace">=C2=A0 =C2=A0 std::size_t size() const { return !em=
pty(); }</font></div></div><div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 auto begin() { return data(); }</font></div></div><div><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 auto end() { return data=
() + size(); }</font></div></div><div><div><font face=3D"courier new, monos=
pace">=C2=A0 =C2=A0 auto begin() const { return data(); }</font></div></div=
><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 auto end() c=
onst { return data() + size(); }</font></div></div><div><div><font face=3D"=
courier new, monospace">};</font></div></div><div><div><font face=3D"courie=
r new, monospace"><br></font></div></div><div><div><font face=3D"courier ne=
w, monospace">template&lt;class T&gt;</font></div></div><div><div><font fac=
e=3D"courier new, monospace">optional_range(std::optional&lt;<wbr>T&gt;&amp=
;&amp;) -&gt; optional_range&lt;std::optional&lt;<wbr>T&gt;&gt;;</font></di=
v></div><div><div><font face=3D"courier new, monospace"><br></font></div></=
div><div><div><font face=3D"courier new, monospace">template&lt;class T&gt;=
</font></div></div><div><div><font face=3D"courier new, monospace">optional=
_range(std::optional&lt;<wbr>T&gt;&amp;) -&gt; optional_range&lt;std::optio=
nal&lt;<wbr>T&gt;&amp;&gt;;</font></div></div><div><div><font face=3D"couri=
er new, monospace"><br></font></div></div><div><div><font face=3D"courier n=
ew, monospace">template&lt;class T&gt;</font></div></div><div><div><font fa=
ce=3D"courier new, monospace">optional_range(std::optional&lt;<wbr>T&gt; co=
nst&amp;) -&gt; optional_range&lt;std::optional&lt;<wbr>T&gt; const&amp;&gt=
;;</font></div></div><div><div><font face=3D"courier new, monospace"><br></=
font></div></div><div><div><font face=3D"courier new, monospace">template&l=
t;class T&gt;</font></div></div><div><div><font face=3D"courier new, monosp=
ace">optional_range(std::optional&lt;<wbr>T&gt; const&amp;&amp;) -&gt; opti=
onal_range&lt;std::optional&lt;<wbr>T&gt;&gt;;</font></div></div></blockquo=
te><div><div><br></div><div>This approach could be easily standardized as a=
n explicit conversion from optional&lt;T&gt; to span&lt;T&gt;.</div></div><=
/div></blockquote><div><br>&quot;Your scientists were so preoccupied with w=
hether or not they could, they didn=E2=80=99t stop to think if they should.=
&quot;</div></div>- Dr. Ian Malcolm (Jurassic Park)<br><br></div><div class=
=3D"gmail_extra">We could make optional into a range, but is it really a go=
od idea? I doubt it.<br></div><div class=3D"gmail_extra">We could also make=
 any object a range of size 1, for example.<br><br></div><div class=3D"gmai=
l_extra">-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div>Be see=
ing 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/CAOHCbitiBfiQq%2ByzrR6eHtWGLu5b3C7MZ%=
3DAwk-Sug4SyyZOaxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitiBfiQ=
q%2ByzrR6eHtWGLu5b3C7MZ%3DAwk-Sug4SyyZOaxA%40mail.gmail.com</a>.<br />

--f403045f155e60f59d054dcd692e--

.

On Sat, Apr 22, 2017 at 7:50 PM, Casey Carter <cartec69@gmail.com> wrote:
> Transforming the optional into a contiguous range seems to optimize well
> (https://godbolt.org/g/RUfWZK):
>

I haven't tried this form.  Better than I thought.

>
> This approach could be easily standardized as an explicit conversion from
> optional<T> to span<T>.

Then this has to be a member function
on optional, and <optional> has to include
<span>*.  What I have in mind is a free
function `if_present`, like `erase_if`,
customizable for each type/class template,
returning ranges of unspecified types.
I don't yet know why these ranges has
to be span<T> and/or contiguous, even
though contiguous range is so far the
most efficient way to implement them,
but IMO this part is still QoI.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent 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/CAGsORuCMq2_fH_jZPsMoM10xxaBAzAEMUz4dMZVVH5Ue6fieTw%40mail.gmail.com.

.

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

On Sat, Apr 22, 2017 at 10:51 PM, Tony V E <tvaneerd@gmail.com> wrote:

> We could make optional into a range, but is it really a good idea? I doubt
> it.
> We could also make any object a range of size 1, for example.
>

Those are two different things.

It is a perfectly valid model that optional is a container of at most one
element.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BM-LkypzFU2R%2B1bh0wViOJ94O1J-gXwr7y%2BmAMT%3Dr%2BMiQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On Sat, Apr 22, 2017 at 10:51 P=
M, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" tar=
get=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_extra">We cou=
ld make optional into a range, but is it really a good idea? I doubt it.<br=
></div><div class=3D"gmail_extra">We could also make any object a range of =
size 1, for example.<br></div></blockquote></div><br>Those are two differen=
t things.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">It is a perfectly valid model that optional is a container of at most o=
ne element.<br>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmai=
l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div=
></div></div></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/CAGg_6%2BM-LkypzFU2R%2B1bh0wViOJ94O1J=
-gXwr7y%2BmAMT%3Dr%2BMiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%=
2BM-LkypzFU2R%2B1bh0wViOJ94O1J-gXwr7y%2BmAMT%3Dr%2BMiQ%40mail.gmail.com</a>=
..<br />

--001a113fb99a86ca3d054dcff57a--

.

------=_Part_960_1134304083.1492943376845
Content-Type: multipart/alternative;
 boundary="----=_Part_961_2135193811.1492943376845"

------=_Part_961_2135193811.1492943376845
Content-Type: text/plain; charset=UTF-8



On Sunday, April 23, 2017 at 1:09:16 AM UTC+2, David Peterson wrote:
>
> Thanks for the feedback.  I'm new to this so didn't realize someone beat
> me to it.  Though I'm more of a hobbyist with C++ in general, I've worked
> with optionals in the past in other languages in a much more professional
> context.  I've found proper implementation and ease of use of optionals can
> seriously increase the stability of a project, especially when newer
> members are introduced to the development team.  I would consider this my
> vote towards the aforementioned proposal.
>
> @Zhihao Yuan, it's good to know that some optimization can occur inside my
> ranged for-loop example.  I still find its usage awkward for optionals, and
> I too have built an implementation around this.  It also doesn't address
> the `else` clause which I feel is very much needed.
>
> I did find out with some serious macro *abuse *that a very close copy of
> this functionality can exist.  I *wouldn't recommend this in production
> code*, of course:
>
> // Badness ensues...
> #define if_has(a, b) if(b) for (a : {*b})
>
> .
> .
> .
>
> if_has(auto& customer, get_customer(customer_id)) {
>     process(customer);
> }
> else {
>     show_customer_not_found();
> }
>
> Since there doesn't seem to be much of a draw for this kind of feature
> natively, I'll just patiently wait in the hopes that more support comes to
> pass.  Thanks again for your review!
>

Your macro is "incorrect" because it evaluate `b` two times, but its fix by
adding `if (auto&& some_local_value = b)`.


Another way to archive that you want could be by extending structur binding
to support syntax:

if(auto [x] = func())
{
    //A
}
else
{
    //B
}

This will be equivalent to:
if(auto __temp = func())
{
    auto&& x = get<0>(__temp);
    //A
}
else
{
    //B
}

Only side effect would be that `std::optional` and pointers (for
consistency) would have need to implements `get<0>` that could be confusing.
Alterative you could add another extension that for `auto [x] = z;`  would
use `auto x = *z;` if `get<0>` is not defined for `z` but this could be
again too much things in one basket.

--
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/8cb2a20d-1642-416c-9b1b-750272f42476%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, April 23, 2017 at 1:09:16 AM UTC+2, Dav=
id Peterson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Thanks for the feedback. =C2=A0I&#39;m new to this so didn&#39;t reali=
ze someone beat me to it. =C2=A0Though I&#39;m more of a hobbyist with C++ =
in general, I&#39;ve worked with optionals in the past in other languages i=
n a much more professional context. =C2=A0I&#39;ve found proper implementat=
ion and ease of use of optionals can seriously increase the stability of a =
project, especially when newer members are introduced to the development te=
am. =C2=A0I would consider this my vote towards the aforementioned proposal=
..<div><br></div><div>@Zhihao Yuan, it&#39;s good to know that some optimiza=
tion can occur inside my ranged for-loop example. =C2=A0I still find its us=
age awkward for optionals, and I too have built an implementation around th=
is. =C2=A0It also doesn&#39;t address the `else` clause which I feel is ver=
y much needed.</div><div><br></div><div>I did find out with some serious ma=
cro <b>abuse </b>that a very close copy of this functionality can exist. =
=C2=A0I <b>wouldn&#39;t recommend this in production code</b>, of course:</=
div><div><br></div><div><div style=3D"color:rgb(212,212,212);background-col=
or:rgb(30,30,30);font-family:Consolas,&quot;Courier New&quot;,monospace;fon=
t-size:14px;line-height:19px"><div><span style=3D"color:#608b4e">//=C2=A0Ba=
dness=C2=A0ensues...</span></div><div><span style=3D"color:#c586c0">#define=
</span><span style=3D"color:#569cd6">=C2=A0</span><span style=3D"color:#dcd=
caa">if_has</span><span style=3D"color:#569cd6">(</span><span style=3D"colo=
r:#9cdcfe">a,=C2=A0b</span><span style=3D"color:#569cd6">)=C2=A0</span><spa=
n style=3D"color:#c586c0">if</span><span style=3D"color:#569cd6">(b)=C2=A0<=
/span><span style=3D"color:#c586c0">for</span><span style=3D"color:#569cd6"=
><wbr>=C2=A0(a=C2=A0:=C2=A0{</span>*<span style=3D"color:#569cd6">b})</span=
></div><br><div>.</div><div>.</div><div>.</div><br><div><span style=3D"colo=
r:#dcdcaa">if_has</span>(<span style=3D"color:#569cd6">auto</span>&amp;=C2=
=A0customer,=C2=A0get_<wbr>customer(customer_id))=C2=A0{</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">process</span>(customer);</=
div><div>}</div><div><span style=3D"color:#c586c0">else</span>=C2=A0{</div>=
<div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">show_customer_no=
t_found</span>();</div><div>}</div></div></div><div><br></div><div>Since th=
ere doesn&#39;t seem to be much of a draw for this kind of feature natively=
, I&#39;ll just patiently wait in the hopes that more support comes to pass=
.. =C2=A0Thanks again for your review!</div></div></blockquote><div><br>Your=
 macro is &quot;incorrect&quot; because it evaluate `b` two times, but its =
fix by adding `if (auto&amp;&amp; some_local_value =3D b)`.<br><br><br>Anot=
her way to archive that you want could be by extending structur binding to =
support syntax:<br><br><div style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; o=
verflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">if</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">au=
to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">]</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
A</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">else</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//B</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></div></code></div><br>This will be equivalent to:<b=
r><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-w=
ord;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">if</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> __temp </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">__temp</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">//A</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">else</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
B</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><br>Only side effect would be that `std::optional` and pointers (for =
consistency) would have need to implements `get&lt;0&gt;` that could be con=
fusing.<br>Alterative you could add another extension that for `auto [x] =
=3D z;`=C2=A0 would use `auto x =3D *z;` if `get&lt;0&gt;` is not defined f=
or `z` but this could be again too much things in one basket.<br><br></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/8cb2a20d-1642-416c-9b1b-750272f42476%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8cb2a20d-1642-416c-9b1b-750272f42476=
%40isocpp.org</a>.<br />

------=_Part_961_2135193811.1492943376845--

------=_Part_960_1134304083.1492943376845--

.

This is a multi-part message in MIME format.
--------------B1E0FFD0AB3C09E0B720B41E
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 23/04/2017 =C3=A0 08:53, Nevin Liber a =C3=A9crit :
> On Sat, Apr 22, 2017 at 10:51 PM, Tony V E <tvaneerd@gmail.com=20
> <mailto:tvaneerd@gmail.com>> wrote:
>
>     We could make optional into a range, but is it really a good idea?
>     I doubt it.
>     We could also make any object a range of size 1, for example.
>
I will say any object that it is not a range to be considered as a range=20
of size 1 ;-)
>
> Those are two different things.
>
> It is a perfectly valid model that optional is a container of at most=20
> one element.

I don't know if making optional a range is a good thing or not, but=20
iterating over the possible value of a nullable type seems right to me.

Following=20
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4127.html, we could=20
have a nullble-based for loop and translate

     for (T x : e1) s2

to

     for (;auto && __p =3D e1; ) { T x =3D *__p; s2 }

when decltype(e1) is nullable.


Vicente

--=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/3c9cf52d-ae32-08f6-3d05-432b4b7ba74c%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 23/04/2017 =C3=A0 08:53, Nevin Liber =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CAGg_6+M-LkypzFU2R+1bh0wViOJ94O1J-gXwr7y+mAMT=3Dr+MiQ@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra">On Sat, Apr 22, 2017 at 10:51 PM, Tony
          V E <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
              href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd=
@gmail.com</a>&gt;</span>
          wrote:<br>
          <div class=3D"gmail_quote">
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class=3D"gmail_extra">We could make optional into a
                range, but is it really a good idea? I doubt it.<br>
              </div>
              <div class=3D"gmail_extra">We could also make any object a
                range of size 1, for example.<br>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    I will say any object that it is not a range to be considered as a
    range of size 1 ;-)<br>
    <blockquote
cite=3D"mid:CAGg_6+M-LkypzFU2R+1bh0wViOJ94O1J-gXwr7y+mAMT=3Dr+MiQ@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra"><br>
          Those are two different things.</div>
        <div class=3D"gmail_extra"><br>
        </div>
        <div class=3D"gmail_extra">It is a perfectly valid model that
          optional is a container of at most one element.</div>
      </div>
    </blockquote>
    <br>
    I don't know if making optional a range is a good thing or not, but
    iterating over the possible value of a nullable type seems right to
    me.<br>
    <br>
    Following
    <a class=3D"moz-txt-link-freetext" href=3D"http://open-std.org/JTC1/SC2=
2/WG21/docs/papers/2014/n4127.html">http://open-std.org/JTC1/SC22/WG21/docs=
/papers/2014/n4127.html</a>, we
    could have a nullble-based for loop and translate<br>
    <br>
    =C2=A0=C2=A0=C2=A0 for (T x : e1) s2<br>
    <br>
    to<br>
    <br>
    =C2=A0=C2=A0=C2=A0 for (;auto &amp;&amp; __p =3D e1; ) { T x =3D *__p; =
s2 }<br>
    <br>
    when decltype(e1) is nullable.<br>
    <br>
    <br>
    Vicente<br>
  </body>
</html>

<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/3c9cf52d-ae32-08f6-3d05-432b4b7ba74c%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c9cf52d-ae32-08f6-3d05-432b4b7ba74c=
%40wanadoo.fr</a>.<br />

--------------B1E0FFD0AB3C09E0B720B41E--

.

------=_Part_1092_954419541.1492980505070
Content-Type: multipart/alternative;
 boundary="----=_Part_1093_450197556.1492980505071"

------=_Part_1093_450197556.1492980505071
Content-Type: text/plain; charset=UTF-8

How about:

if ([auto& customer] = get_customer(customer_id)) {
    process(customer);
}
else {
    show_customer_not_found();
}

This extends structured bindings to allow "trying" to bind a result. Of
course, to prevent using invalid references in case of a failed binding,
this should only compile in the context of an if statement, and the binded
reference should only be visible within the if part, not the else part.

Thanks,
Dan

On Saturday, April 22, 2017 at 11:23:52 PM UTC+2, David Peterson wrote:
>
> Hi Everyone, this is my first time floating an idea so apologies if I get
> the format wrong.  Constructive criticism is very welcome!
>
> I've had a look at the new std::optional<T> and as exciting as it is to
> finally have such a useful type in the standard, I worry that the feature
> may be too cumbersome and possibly too easy to use incorrectly.  Here's an
> example of its current usage as provided by the C++ 17 standard:
>
> // C++ 17 New Optional Usage //
> if (auto customer = get_customer(customer_id)) {
>     process(*customer);
> }
> else {
>     show_customer_not_found();
> }
>
> This isn't too bad, but I think it could be better.  The first issue I
> have is with `customer` being an actual std::optional instance.  This
> creates a level of indirection that seems awkward to use.  One must also
> remember to dereference the `customer` optional when attempting to gain
> access to the value as can be seen during the `process` call.  It would be
> nice to remove this indirection and gain direct access to the underlying
> type rather than through the optional itself.  After some thinking, I
> realized that the range-based for loop had the solution I was looking for.
>  Essentially, an optional is a list containing either no items or exactly
> one item.  In such a case, one could think of iterating over an optional as
> if it were a simple container:
>
> // Example of an optional as if it were a container of one or zero items //
> for (auto& customer : get_customer(customer_id)) {
>     process(customer);
> }
>
> Obviously, this syntax is a bit awkward.  It just doesn't make sense to
> consider an optional as a container.  Furthermore, there would likely be a
> high degree of unnecessary overhead in interpreting the optional as a
> container.  Iterators would also have to be made to support the begin/end
> range.  To correct these shortcomings, my proposal is to extend the
> range-based for loop syntax for single instance item which may or may not
> exist (optionals and pointers, primarily) to the `if` statement.  Here is
> an example:
>
> // New way with `if` auto-dereferencing language feature //
> if (auto& customer : get_customer(customer_id)) {
>     process(customer); // customer is a Customer& and not an optional.
>                        // We can safely use customer as we are guaranteed
>                        // to have a valid reference and that reference
>                        // cannot extend beyond the `if` scope
> }
> else {
>     show_customer_not_found();
> }
>
> As you can see, this feature is readable and addresses the indirection
> problem from earlier.  Furthermore, it can be optimized easier for optional
> types and can theoretically work with any type, including user types, so
> long as they provide a conversion to boolean operator and a dereference
> operator.  An example of how this could be interpreted follows:
>
> // New feature translates into... //
> auto _optional_customer = get_customer(customer_id);
> if (_optional_customer) {
>     auto& customer = *_optional_customer;
>     process(customer);
> }
> else {
>     show_customer_not_found();
> }
>
> I'm sure language features are not the easiest thing to add, and I'm no
> compiler developer, but I'm anxious to hear any feedback you may have in
> regards to short comings, enhancements and overall complexity to implement.
>  Thank you for considering this feature. - David Peterson
>

--
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/0f561d00-a65f-4810-bca6-4ac43372f778%40isocpp.org.

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

<div dir=3D"ltr">How about:<div><br></div><div><div style=3D"color: rgb(212=
, 212, 212); font-family: Consolas, &#39;Courier New&#39;, monospace; font-=
size: 14px; background-color: rgb(30, 30, 30);"><span style=3D"color: rgb(1=
97, 134, 192);">if</span>=C2=A0([<span style=3D"color: rgb(86, 156, 214);">=
auto&amp;</span>=C2=A0customer] =3D=C2=A0get_<wbr>customer(customer_id))=C2=
=A0{<br></div><div style=3D"color: rgb(212, 212, 212); font-family: Consola=
s, &#39;Courier New&#39;, monospace; font-size: 14px; background-color: rgb=
(30, 30, 30);">=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: rgb(220, 220, =
170);">process</span>(customer);</div><div style=3D"color: rgb(212, 212, 21=
2); font-family: Consolas, &#39;Courier New&#39;, monospace; font-size: 14p=
x; background-color: rgb(30, 30, 30);">}</div><div style=3D"color: rgb(212,=
 212, 212); font-family: Consolas, &#39;Courier New&#39;, monospace; font-s=
ize: 14px; background-color: rgb(30, 30, 30);"><span style=3D"color: rgb(19=
7, 134, 192);">else</span>=C2=A0{</div><div style=3D"color: rgb(212, 212, 2=
12); font-family: Consolas, &#39;Courier New&#39;, monospace; font-size: 14=
px; background-color: rgb(30, 30, 30);">=C2=A0=C2=A0=C2=A0=C2=A0<span style=
=3D"color: rgb(220, 220, 170);">show_customer_not_found</span>();</div><div=
 style=3D"color: rgb(212, 212, 212); font-family: Consolas, &#39;Courier Ne=
w&#39;, monospace; font-size: 14px; background-color: rgb(30, 30, 30);">}</=
div><div><br></div><div>This extends structured bindings to allow &quot;try=
ing&quot; to bind a result. Of course, to prevent using invalid references =
in case of a failed binding, this should only compile in the context of an =
if statement, and the binded reference should only be visible within the if=
 part, not the else part.</div><div><br></div><div>Thanks,</div><div>Dan</d=
iv><br>On Saturday, April 22, 2017 at 11:23:52 PM UTC+2, David Peterson wro=
te:<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">Hi Everyon=
e, this is my first time floating an idea so apologies if I get the format =
wrong. =C2=A0Constructive criticism is very welcome!<div><br></div><div>I&#=
39;ve had a look at the new std::optional&lt;T&gt; and as exciting as it is=
 to finally have such a useful type in the standard, I worry that the featu=
re may be too cumbersome and possibly too easy to use incorrectly. =C2=A0He=
re&#39;s an example of its current usage as provided by the C++ 17 standard=
:</div><div><br></div><div><div style=3D"color:rgb(212,212,212);background-=
color:rgb(30,30,30);font-family:Consolas,&quot;Courier New&quot;,monospace;=
font-size:14px;line-height:19px"><div><span style=3D"color:#608b4e">//=C2=
=A0C++=C2=A017=C2=A0New=C2=A0Optional Usage //</span></div><div><span style=
=3D"color:#c586c0">if</span>=C2=A0(<span style=3D"color:#569cd6">auto</span=
>=C2=A0customer=C2=A0=3D=C2=A0get_<wbr>customer(customer_id))=C2=A0{</div><=
div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">process</span>(*c=
ustomer);</div><div>}</div><div><span style=3D"color:#c586c0">else</span>=
=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">sho=
w_customer_not_found</span>();</div><div>}</div></div></div><div><br></div>=
<div>This isn&#39;t too bad, but I think it could be better. =C2=A0The firs=
t issue I have is with `customer` being an actual std::optional instance. =
=C2=A0This creates a level of indirection that seems awkward to use. =C2=A0=
One must also remember to dereference the `customer` optional when attempti=
ng to gain access to the value as can be seen during the `process` call. =
=C2=A0It would be nice to remove this indirection and gain direct access to=
 the underlying type rather than through the optional itself. =C2=A0After s=
ome thinking, I realized that the range-based for loop had the solution I w=
as looking for. =C2=A0Essentially, an optional is a list containing either =
no items or exactly one item. =C2=A0In such a case, one could think of iter=
ating over an optional as if it were a simple container:</div><div><br></di=
v><div><div style=3D"color:rgb(212,212,212);background-color:rgb(30,30,30);=
font-family:Consolas,&quot;Courier New&quot;,monospace;font-size:14px;line-=
height:19px"><div><span style=3D"color:#608b4e">//=C2=A0Example=C2=A0of=C2=
=A0an=C2=A0optional=C2=A0as=C2=A0<wbr>if=C2=A0it=C2=A0were=C2=A0a=C2=A0cont=
ainer=C2=A0of=C2=A0one=C2=A0<wbr>or=C2=A0zero=C2=A0items=C2=A0//</span></di=
v><div><span style=3D"color:#c586c0">for</span>=C2=A0(<span style=3D"color:=
#569cd6">auto</span>&amp;=C2=A0customer=C2=A0:=C2=A0get_<wbr>customer(custo=
mer_id))=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcd=
caa">process</span>(customer);</div><div>}</div></div></div><div><br></div>=
<div>Obviously, this syntax is a bit awkward. =C2=A0It just doesn&#39;t mak=
e sense to consider an optional as a container. =C2=A0Furthermore, there wo=
uld likely be a high degree of unnecessary overhead in interpreting the opt=
ional as a container. =C2=A0Iterators would also have to be made to support=
 the begin/end range. =C2=A0To correct these shortcomings, my proposal is t=
o extend the range-based for loop syntax for single instance item which may=
 or may not exist (optionals and pointers, primarily) to the `if` statement=
.. =C2=A0Here is an example:</div><div><br></div><div><div style=3D"color:rg=
b(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,&quot;Co=
urier New&quot;,monospace;font-size:14px;line-height:19px"><div><div style=
=3D"line-height:19px"><div><span style=3D"color:#608b4e">//=C2=A0New=C2=A0w=
ay=C2=A0with=C2=A0`if` auto-dereferencing language=C2=A0feature=C2=A0//</sp=
an></div><div><span style=3D"color:#c586c0">if</span>=C2=A0(<span style=3D"=
color:#569cd6">auto</span>&amp;=C2=A0customer=C2=A0:=C2=A0get_<wbr>customer=
(customer_id))=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"colo=
r:#dcdcaa">process</span>(customer);=C2=A0<span style=3D"color:#608b4e">//=
=C2=A0<wbr>customer=C2=A0is=C2=A0a=C2=A0Customer&amp;=C2=A0and=C2=A0<wbr>no=
t=C2=A0an=C2=A0optional.</span></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#608b4e">//=C2=A0We=C2=
=A0<wbr>can=C2=A0safely=C2=A0use=C2=A0customer=C2=A0as=C2=A0we=C2=A0<wbr>ar=
e=C2=A0guaranteed</span></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#608b4e">//=C2=A0to=C2=A0<wbr>=
have=C2=A0a=C2=A0valid=C2=A0reference=C2=A0and=C2=A0<wbr>that=C2=A0referenc=
e</span></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:#608b4e">//=C2=A0<wbr>cannot=C2=A0extend=C2=
=A0beyond=C2=A0the `if` scope</span></div><div>}</div><div><span style=3D"c=
olor:#c586c0">else</span>=C2=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span st=
yle=3D"color:#dcdcaa">show_customer_not_found</span>();</div><div>}</div></=
div></div></div></div><div><br></div><div>As you can see, this feature is r=
eadable and addresses the indirection problem from earlier. =C2=A0Furthermo=
re, it can be optimized easier for optional types and can theoretically wor=
k with any type, including user types, so long as they provide a conversion=
 to boolean operator and a dereference operator. =C2=A0An example of how th=
is could be interpreted follows:</div><div><br></div><div><div style=3D"col=
or:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,&qu=
ot;Courier New&quot;,monospace;font-size:14px;line-height:19px"><div><span =
style=3D"color:#608b4e">//=C2=A0New=C2=A0feature=C2=A0translates=C2=A0<wbr>=
into...=C2=A0//</span></div><div><span style=3D"color:#569cd6">auto</span>=
=C2=A0_optional_customer=C2=A0=3D=C2=A0get_<wbr>customer(customer_id);</div=
><div><span style=3D"color:#c586c0">if</span>=C2=A0(_optional_customer)=C2=
=A0{</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#569cd6">auto</=
span>&amp;=C2=A0customer=C2=A0=3D=C2=A0*_<wbr>optional_customer;</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">process</span>(custom=
er);</div><div>}</div><div><span style=3D"color:#c586c0">else</span>=C2=A0{=
</div><div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">show_custo=
mer_not_found</span>();</div><div>}</div></div></div><div><br></div><div>I&=
#39;m sure language features are not the easiest thing to add, and I&#39;m =
no compiler developer, but I&#39;m anxious to hear any feedback you may hav=
e in regards to short comings, enhancements and overall complexity to imple=
ment. =C2=A0Thank you for considering this feature. - David Peterson</div><=
/div></blockquote></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/0f561d00-a65f-4810-bca6-4ac43372f778%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f561d00-a65f-4810-bca6-4ac43372f778=
%40isocpp.org</a>.<br />

------=_Part_1093_450197556.1492980505071--

------=_Part_1092_954419541.1492980505070--

.

------=_Part_1508_167299092.1493090298216
Content-Type: multipart/alternative;
 boundary="----=_Part_1509_535545065.1493090298216"

------=_Part_1509_535545065.1493090298216
Content-Type: text/plain; charset=UTF-8



> Your macro is "incorrect" because it evaluate `b` two times, but its fix
> by adding `if (auto&& some_local_value = b)`.
>
>
>
>
That's true.  I threw that together, so I didn't really test it for that
case.  Thanks for the catch. I was trying to avoid creating a temporary in
an attempt to avoid name conflicts during nesting.

--
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/77d94537-6b4e-4238-acfb-ae0564f8abb5%40isocpp.org.

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

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Your macro is &quot;incorrect&quot; because it evaluate `b` t=
wo times, but its fix by adding `if (auto&amp;&amp; some_local_value =3D b)=
`.<br><br><br><br></div></div></blockquote><div><br></div><div>That&#39;s t=
rue. =C2=A0I threw that together, so I didn&#39;t really test it for that c=
ase. =C2=A0Thanks for the catch. I was trying to avoid creating a temporary=
 in an attempt to avoid name conflicts during nesting.</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/77d94537-6b4e-4238-acfb-ae0564f8abb5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77d94537-6b4e-4238-acfb-ae0564f8abb5=
%40isocpp.org</a>.<br />

------=_Part_1509_535545065.1493090298216--

------=_Part_1508_167299092.1493090298216--

.

------=_Part_2473_1340505316.1493166097583
Content-Type: multipart/alternative;
 boundary="----=_Part_2474_1240654592.1493166097584"

------=_Part_2474_1240654592.1493166097584
Content-Type: text/plain; charset=UTF-8



On Sunday, April 23, 2017 at 4:51:57 AM UTC+1, Tony V E wrote:
>
>
> We could also make any object a range of size 1, for example.
>

Correct me if I'm wrong, but isn't this precisely what Range-V3's
view::single does?

A can appreciate not wanting to clutter optional's interface with begin()
and end() member functions etc, but providing a wrapper view as in Casey's
example seems to me like it would be useful.

Tristan

--
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/134e84a0-b46a-4ace-b0da-e6d71f188fd2%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, April 23, 2017 at 4:51:57 AM UTC+1, Ton=
y V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br><div><div class=3D"gmail_quote">We could also make any object a range of=
 size 1, for example.<br></div></div></div></blockquote><div><br></div><div=
>Correct me if I&#39;m wrong, but isn&#39;t this precisely what Range-V3&#3=
9;s <font face=3D"courier new, monospace">view::single</font> does?</div><d=
iv><br></div><div>A can appreciate not wanting to clutter <font face=3D"cou=
rier new, monospace">optional</font>&#39;s interface with <font face=3D"cou=
rier new, monospace">begin()</font> and <font face=3D"courier new, monospac=
e">end()</font><font face=3D"arial, sans-serif">=C2=A0member</font>=C2=A0fu=
nctions etc, but providing a wrapper view as in Casey&#39;s example seems t=
o me like it would be useful.</div><div><br></div><div>Tristan</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/134e84a0-b46a-4ace-b0da-e6d71f188fd2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/134e84a0-b46a-4ace-b0da-e6d71f188fd2=
%40isocpp.org</a>.<br />

------=_Part_2474_1240654592.1493166097584--

------=_Part_2473_1340505316.1493166097583--

.

This is a multi-part message in MIME format.
--------------A745FB230A8FB843322CAFAD
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 26/04/2017 =C3=A0 02:21, Tristan Brindle a =C3=A9crit :
>
>
> On Sunday, April 23, 2017 at 4:51:57 AM UTC+1, Tony V E wrote:
>
>
>     We could also make any object a range of size 1, for example.
>
>
> Correct me if I'm wrong, but isn't this precisely what Range-V3's=20
> view::single does?
I don't think so. You will need a view::nullable.
>
> A can appreciate not wanting to clutter optional's interface with=20
> begin() and end() member functions etc,
These functions can be non-members :)
> but providing a wrapper view as in Casey's example seems to me like it=20
> would be useful.
>
Sure, this could be useful in some cases.

I believe the question of this thread is if we want to iterate over the=20
possible value directly even if optional is not a model of Range without=20
adding any noise.
There are other ways to iterate over an object than using a Range e.g.=20
Nullables and Functors could allow iteration over its elements.

If we had several forms of XXX-based for loops, the implementation could=20
take the concept that is more constrained as it his implementation=20
should/could be more efficient than the less constrained one.

Vicente

--=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/2ca1552a-6901-c4c7-6b5d-e7237f1320a0%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 26/04/2017 =C3=A0 02:21, Tristan Brin=
dle
      a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:134e84a0-b46a-4ace-b0da-e6d71f188fd2@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Sunday, April 23, 2017 at 4:51:57 AM UTC+1, Tony V E 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"><br>
            <div>
              <div class=3D"gmail_quote">We could also make any object a
                range of size 1, for example.<br>
              </div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Correct me if I'm wrong, but isn't this precisely what
          Range-V3's <font face=3D"courier new, monospace">view::single</fo=
nt>
          does?</div>
      </div>
    </blockquote>
    I don't think so. You will need a view::nullable.<br>
    <blockquote
      cite=3D"mid:134e84a0-b46a-4ace-b0da-e6d71f188fd2@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>A can appreciate not wanting to clutter <font
            face=3D"courier new, monospace">optional</font>'s interface
          with <font face=3D"courier new, monospace">begin()</font> and <fo=
nt
            face=3D"courier new, monospace">end()</font><font face=3D"arial=
,
            sans-serif">=C2=A0member</font>=C2=A0functions etc, </div>
      </div>
    </blockquote>
    These functions can be non-members :)<br>
    <blockquote
      cite=3D"mid:134e84a0-b46a-4ace-b0da-e6d71f188fd2@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>but providing a wrapper view as in Casey's example seems to
          me like it would be useful.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    Sure, this could be useful in some cases.<br>
    =C2=A0<br>
    I believe the question of this thread is if we want to iterate over
    the possible value directly even if optional is not a model of Range
    without adding any noise.<br>
    There are other ways to iterate over an object than using a Range
    e.g. Nullables and Functors could allow iteration over its elements.<br=
>
    <br>
    If we had several forms of XXX-based for loops, the implementation
    could take the concept that is more constrained as it his
    implementation should/could be more efficient than the less
    constrained one.<br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<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/2ca1552a-6901-c4c7-6b5d-e7237f1320a0%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ca1552a-6901-c4c7-6b5d-e7237f1320a0=
%40wanadoo.fr</a>.<br />

--------------A745FB230A8FB843322CAFAD--

.

This is a multi-part message in MIME format.
--------------B5C99A8F740FD685DBF136D2
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 22/04/2017 =C3=A0 23:23, David Peterson a =C3=A9crit :
> Hi Everyone, this is my first time floating an idea so apologies if I=20
> get the format wrong.  Constructive criticism is very welcome!
>
> I've had a look at the new std::optional<T> and as exciting as it is=20
> to finally have such a useful type in the standard, I worry that the=20
> feature may be too cumbersome and possibly too easy to use=20
> incorrectly.  Here's an example of its current usage as provided by=20
> the C++ 17 standard:
>
> // C++ 17 New Optional Usage //
> if (auto customer =3D get_customer(customer_id)) {
> process(*customer);
> }
> else {
> show_customer_not_found();
> }
>
> This isn't too bad, but I think it could be better.  The first issue I=20
> have is with `customer` being an actual std::optional instance.  This=20
> creates a level of indirection that seems awkward to use.  One must=20
> also remember to dereference the `customer` optional when attempting=20
> to gain access to the value as can be seen during the `process` call.=20
>  It would be nice to remove this indirection and gain direct access to=20
> the underlying type rather than through the optional itself.
<snip>
>   To correct these shortcomings, my proposal is to extend the=20
> range-based for loop syntax for single instance item which may or may=20
> not exist (optionals and pointers, primarily) to the `if` statement.=20
>  Here is an example:
>
> // New way with `if` auto-dereferencing language feature //
>
> if (auto& customer : get_customer(customer_id)) {
> process(customer); // customer is a Customer& and not an optional.
> // We can safely use customer as we are guaranteed
> // to have a valid reference and that reference
> // cannot extend beyond the `if` scope
> }
> else {
> show_customer_not_found();
> }
>
> As you can see, this feature is readable and addresses the indirection=20
> problem from earlier.  Furthermore, it can be optimized easier for=20
> optional types and can theoretically work with any type, including=20
> user types, so long as they provide a conversion to boolean operator=20
> and a dereference operator.  An example of how this could be=20
> interpreted follows:
>
> // New feature translates into... //
> auto _optional_customer =3D get_customer(customer_id);
> if (_optional_customer) {
> auto& customer =3D *_optional_customer;
> process(customer);
> }
> else {
> show_customer_not_found();
> }
>
> I'm sure language features are not the easiest thing to add, and I'm=20
> no compiler developer, but I'm anxious to hear any feedback you may=20
> have in regards to short comings, enhancements and overall complexity=20
> to implement.  Thank you for considering this feature. - David Peterson
The language based variant proposal [1] (I hope will be part of C++20)=20
will allow to do pattern matching.
I believe this will be more adapted and will take in account=20
std::expected as well.

We could have something like

inspect  (get_customer(customer_id)) {
     just customer =3D>    process(customer);
     nothing =3D>  show_customer_not_found();
}

once std::optional would be adapted  to the patter matching constraints.

Vicente

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0095r1.html

--=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/921cd9f6-f26b-c674-6609-d924cf7d2758%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 22/04/2017 =C3=A0 23:23, David Peters=
on a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:bacbf6b9-06a8-4f30-b8f0-74a85a875191@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Hi Everyone, this is my first time floating an idea
        so apologies if I get the format wrong. =C2=A0Constructive criticis=
m
        is very welcome!
        <div><br>
        </div>
        <div>I've had a look at the new std::optional&lt;T&gt; and as
          exciting as it is to finally have such a useful type in the
          standard, I worry that the feature may be too cumbersome and
          possibly too easy to use incorrectly. =C2=A0Here's an example of
          its current usage as provided by the C++ 17 standard:</div>
        <div><br>
        </div>
        <div>
          <div style=3D"color: rgb(212, 212, 212); background-color:
            rgb(30, 30, 30); font-family: Consolas, &quot;Courier
            New&quot;, monospace; font-size: 14px; line-height: 19px;">
            <div><span style=3D"color: #608b4e;">//=C2=A0C++=C2=A017=C2=A0N=
ew=C2=A0Optional
                Usage //</span></div>
            <div><span style=3D"color: #c586c0;">if</span>=C2=A0(<span
                style=3D"color: #569cd6;">auto</span>=C2=A0customer=C2=A0=
=3D=C2=A0get_customer(customer_id))=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #dcdcaa;">pr=
ocess</span>(*customer);</div>
            <div>}</div>
            <div><span style=3D"color: #c586c0;">else</span>=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #dcdcaa;">sh=
ow_customer_not_found</span>();</div>
            <div>}</div>
          </div>
        </div>
        <div><br>
        </div>
        <div>This isn't too bad, but I think it could be better. =C2=A0The
          first issue I have is with `customer` being an actual
          std::optional instance. =C2=A0This creates a level of indirection
          that seems awkward to use. =C2=A0One must also remember to
          dereference the `customer` optional when attempting to gain
          access to the value as can be seen during the `process` call.
          =C2=A0It would be nice to remove this indirection and gain direct
          access to the underlying type rather than through the optional
          itself.=C2=A0 <br>
        </div>
      </div>
    </blockquote>
    &lt;snip&gt;<br>
    <blockquote
      cite=3D"mid:bacbf6b9-06a8-4f30-b8f0-74a85a875191@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">=C2=A0 To correct these shortcomings, my proposal is=
 to
        extend the range-based for loop syntax for single instance item
        which may or may not exist (optionals and pointers, primarily)
        to the `if` statement. =C2=A0Here is an example:
        <div><br>
        </div>
        <div>
          <div style=3D"color: rgb(212, 212, 212); background-color:
            rgb(30, 30, 30); font-family: Consolas, &quot;Courier
            New&quot;, monospace; font-size: 14px; line-height: 19px;">
            <div>
              <div style=3D"line-height: 19px;">
                <div><span style=3D"color: #608b4e;">//=C2=A0New=C2=A0way=
=C2=A0with=C2=A0`if`
                    auto-dereferencing language=C2=A0feature=C2=A0//</span>=
</div>
                <br>
                <div><span style=3D"color: #c586c0;">if</span>=C2=A0(<span
                    style=3D"color: #569cd6;">auto</span>&amp;=C2=A0custome=
r=C2=A0:=C2=A0get_customer(customer_id))=C2=A0{</div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #dcdcaa;=
">process</span>(customer);=C2=A0<span
                    style=3D"color: #608b4e;">//=C2=A0customer=C2=A0is=C2=
=A0a=C2=A0Customer&amp;=C2=A0and=C2=A0not=C2=A0an=C2=A0optional.</span></di=
v>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:
                    #608b4e;">//=C2=A0We=C2=A0can=C2=A0safely=C2=A0use=C2=
=A0customer=C2=A0as=C2=A0we=C2=A0are=C2=A0guaranteed</span></div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:
                    #608b4e;">//=C2=A0to=C2=A0have=C2=A0a=C2=A0valid=C2=A0r=
eference=C2=A0and=C2=A0that=C2=A0reference</span></div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:
                    #608b4e;">//=C2=A0cannot=C2=A0extend=C2=A0beyond=C2=A0t=
he `if` scope</span></div>
                <div>}</div>
                <div><span style=3D"color: #c586c0;">else</span>=C2=A0{</di=
v>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #dcdcaa;=
">show_customer_not_found</span>();</div>
                <div>}</div>
              </div>
            </div>
          </div>
        </div>
        <div><br>
        </div>
        <div>As you can see, this feature is readable and addresses the
          indirection problem from earlier. =C2=A0Furthermore, it can be
          optimized easier for optional types and can theoretically work
          with any type, including user types, so long as they provide a
          conversion to boolean operator and a dereference operator. =C2=A0=
An
          example of how this could be interpreted follows:</div>
        <div><br>
        </div>
        <div>
          <div style=3D"color: rgb(212, 212, 212); background-color:
            rgb(30, 30, 30); font-family: Consolas, &quot;Courier
            New&quot;, monospace; font-size: 14px; line-height: 19px;">
            <div><span style=3D"color: #608b4e;">//=C2=A0New=C2=A0feature=
=C2=A0translates=C2=A0into...=C2=A0//</span></div>
            <div><span style=3D"color: #569cd6;">auto</span>=C2=A0_optional=
_customer=C2=A0=3D=C2=A0get_customer(customer_id);</div>
            <div><span style=3D"color: #c586c0;">if</span>=C2=A0(_optional_=
customer)=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #569cd6;">au=
to</span>&amp;=C2=A0customer=C2=A0=3D=C2=A0*_optional_customer;</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #dcdcaa;">pr=
ocess</span>(customer);</div>
            <div>}</div>
            <div><span style=3D"color: #c586c0;">else</span>=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color: #dcdcaa;">sh=
ow_customer_not_found</span>();</div>
            <div>}</div>
          </div>
        </div>
        <div><br>
        </div>
        <div>I'm sure language features are not the easiest thing to
          add, and I'm no compiler developer, but I'm anxious to hear
          any feedback you may have in regards to short comings,
          enhancements and overall complexity to implement. =C2=A0Thank you
          for considering this feature. - David Peterson</div>
      </div>
    </blockquote>
    The language based variant proposal [1] (I hope will be part of
    C++20) will allow to do pattern matching.<br>
    I believe this will be more adapted and will take in account
    std::expected as well.<br>
    <br>
    We could have something like<br>
    <br>
    <div><font color=3D"#3333ff">inspect</font>=C2=A0 (get_customer(custome=
r_id))=C2=A0{</div>
    <div>=C2=A0=C2=A0=C2=A0 just customer =3D&gt; =C2=A0=C2=A0 process(cust=
omer);</div>
    <div>=C2=A0=C2=A0=C2=A0 nothing =3D&gt;=C2=A0 show_customer_not_found()=
;</div>
    <div>}</div>
    <br>
    once std::optional would be adapted=C2=A0 to the patter matching
    constraints. <br>
    <br>
    Vicente<br>
    <br>
    [1]
    <a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2016/p0095r1.html">http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2016/p0095r1.html</a><br>
  </body>
</html>

<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/921cd9f6-f26b-c674-6609-d924cf7d2758%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/921cd9f6-f26b-c674-6609-d924cf7d2758=
%40wanadoo.fr</a>.<br />

--------------B5C99A8F740FD685DBF136D2--

.

------=_Part_3791_325996676.1493312092026
Content-Type: multipart/alternative;
 boundary="----=_Part_3792_2099221978.1493312092026"

------=_Part_3792_2099221978.1493312092026
Content-Type: text/plain; charset=UTF-8


>
> The language based variant proposal [1] (I hope will be part of C++20)
> will allow to do pattern matching.I believe this will be more adapted and
> will take in account std::expected as well.


This looks similar to Rust's enumeration and pattern matching.  In all
honesty, I think I would prefer this pattern matching system to a built in
optional.  This seems extremely flexible and could be used for run-time
validation as well (such as a variant which is either a SuccessObject or a
FailureObject after a process completes).  I hope that templating is
included when (if?) the proposal is ratified as this would easily solve the
issue with optionals in a very safe, easy to use way.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2a4b389-936c-4e2a-845a-ddccca84262c%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
The language based variant proposal [1] (I hope will be part of C++20) will=
 allow to do pattern matching.I believe this will be more adapted and will =
take in account std::expected as well.</blockquote><div>=C2=A0</div><div>Th=
is looks similar to Rust&#39;s enumeration and pattern matching. =C2=A0In a=
ll honesty, I think I would prefer this pattern matching system to a built =
in optional. =C2=A0This seems extremely flexible and could be used for run-=
time validation as well (such as a variant which is either a SuccessObject =
or a FailureObject after a process completes). =C2=A0I hope that templating=
 is included when (if?) the proposal is ratified as this would easily solve=
 the issue with optionals in a very safe, easy to use way.</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/b2a4b389-936c-4e2a-845a-ddccca84262c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2a4b389-936c-4e2a-845a-ddccca84262c=
%40isocpp.org</a>.<br />

------=_Part_3792_2099221978.1493312092026--

------=_Part_3791_325996676.1493312092026--

.

------=_Part_2098_598995485.1493320432978
Content-Type: multipart/alternative;
 boundary="----=_Part_2099_1535902488.1493320432979"

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

+1 for this.
But even if we don't get language based variants, is there any good reason=
=20
why optional<T> couldn't be implemented as a variant<nullopt_t, T> ? Which=
=20
would solve the original issue brought up here by just allowing std::visit=
=20
to be used.

Cheers,
Dan

On Thursday, April 27, 2017 at 8:33:50 AM UTC+2, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 22/04/2017 =C3=A0 23:23, David Peterson a =C3=A9crit :
>
> Hi Everyone, this is my first time floating an idea so apologies if I get=
=20
> the format wrong.  Constructive criticism is very welcome!=20
>
> I've had a look at the new std::optional<T> and as exciting as it is to=
=20
> finally have such a useful type in the standard, I worry that the feature=
=20
> may be too cumbersome and possibly too easy to use incorrectly.  Here's a=
n=20
> example of its current usage as provided by the C++ 17 standard:
>
> // C++ 17 New Optional Usage //
> if (auto customer =3D get_customer(customer_id)) {
>     process(*customer);
> }
> else {
>     show_customer_not_found();
> }
>
> This isn't too bad, but I think it could be better.  The first issue I=20
> have is with `customer` being an actual std::optional instance.  This=20
> creates a level of indirection that seems awkward to use.  One must also=
=20
> remember to dereference the `customer` optional when attempting to gain=
=20
> access to the value as can be seen during the `process` call.  It would b=
e=20
> nice to remove this indirection and gain direct access to the underlying=
=20
> type rather than through the optional itself. =20
>
> <snip>
>
>   To correct these shortcomings, my proposal is to extend the range-based=
=20
> for loop syntax for single instance item which may or may not exist=20
> (optionals and pointers, primarily) to the `if` statement.  Here is an=20
> example:=20
>
> // New way with `if` auto-dereferencing language feature //
>
> if (auto& customer : get_customer(customer_id)) {
>     process(customer); // customer is a Customer& and not an optional.
>                        // We can safely use customer as we are guaranteed
>                        // to have a valid reference and that reference
>                        // cannot extend beyond the `if` scope
> }
> else {
>     show_customer_not_found();
> }
>
> As you can see, this feature is readable and addresses the indirection=20
> problem from earlier.  Furthermore, it can be optimized easier for option=
al=20
> types and can theoretically work with any type, including user types, so=
=20
> long as they provide a conversion to boolean operator and a dereference=
=20
> operator.  An example of how this could be interpreted follows:
>
> // New feature translates into... //
> auto _optional_customer =3D get_customer(customer_id);
> if (_optional_customer) {
>     auto& customer =3D *_optional_customer;
>     process(customer);
> }
> else {
>     show_customer_not_found();
> }
>
> I'm sure language features are not the easiest thing to add, and I'm no=
=20
> compiler developer, but I'm anxious to hear any feedback you may have in=
=20
> regards to short comings, enhancements and overall complexity to implemen=
t.=20
>  Thank you for considering this feature. - David Peterson
>
> The language based variant proposal [1] (I hope will be part of C++20)=20
> will allow to do pattern matching.
> I believe this will be more adapted and will take in account std::expecte=
d=20
> as well.
>
> We could have something like
>
> inspect  (get_customer(customer_id)) {
>     just customer =3D>    process(customer);
>     nothing =3D>  show_customer_not_found();
> }
>
> once std::optional would be adapted  to the patter matching constraints.=
=20
>
> Vicente
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0095r1.html
>

--=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/ebc016e5-db8a-43e0-adf6-0f4e592cec78%40isocpp.or=
g.

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

<div dir=3D"ltr">+1 for this.<div>But even if we don&#39;t get language bas=
ed variants, is there any good reason why optional&lt;T&gt; couldn&#39;t be=
 implemented as a variant&lt;nullopt_t, T&gt; ? Which would solve the origi=
nal issue brought up here by just allowing std::visit to be used.</div><div=
><br></div><div>Cheers,</div><div>Dan<br><br>On Thursday, April 27, 2017 at=
 8:33:50 AM UTC+2, Vicente J. Botet Escriba wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 22/04/2017 =C3=A0 23:23, David Peterson a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">Hi Everyone, this is my first time floating an idea
        so apologies if I get the format wrong. =C2=A0Constructive criticis=
m
        is very welcome!
        <div><br>
        </div>
        <div>I&#39;ve had a look at the new std::optional&lt;T&gt; and as
          exciting as it is to finally have such a useful type in the
          standard, I worry that the feature may be too cumbersome and
          possibly too easy to use incorrectly. =C2=A0Here&#39;s an example=
 of
          its current usage as provided by the C++ 17 standard:</div>
        <div><br>
        </div>
        <div>
          <div>
            <div><span style=3D"color:#608b4e">//=C2=A0C++=C2=A017=C2=A0New=
=C2=A0Optional
                Usage //</span></div>
            <div><span style=3D"color:#c586c0">if</span>=C2=A0(<span style=
=3D"color:#569cd6">auto</span>=C2=A0customer=C2=A0=3D=C2=A0get_<wbr>custome=
r(customer_id))=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">proc=
ess</span>(*customer);</div>
            <div>}</div>
            <div><span style=3D"color:#c586c0">else</span>=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">show=
_customer_not_found</span>();</div>
            <div>}</div>
          </div>
        </div>
        <div><br>
        </div>
        <div>This isn&#39;t too bad, but I think it could be better. =C2=A0=
The
          first issue I have is with `customer` being an actual
          std::optional instance. =C2=A0This creates a level of indirection
          that seems awkward to use. =C2=A0One must also remember to
          dereference the `customer` optional when attempting to gain
          access to the value as can be seen during the `process` call.
          =C2=A0It would be nice to remove this indirection and gain direct
          access to the underlying type rather than through the optional
          itself.=C2=A0 <br>
        </div>
      </div>
    </blockquote>
    &lt;snip&gt;<br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">=C2=A0 To correct these shortcomings, my proposal is=
 to
        extend the range-based for loop syntax for single instance item
        which may or may not exist (optionals and pointers, primarily)
        to the `if` statement. =C2=A0Here is an example:
        <div><br>
        </div>
        <div>
          <div>
            <div>
              <div style=3D"line-height:19px">
                <div><span style=3D"color:#608b4e">//=C2=A0New=C2=A0way=C2=
=A0with=C2=A0`if`
                    auto-dereferencing language=C2=A0feature=C2=A0//</span>=
</div>
                <br>
                <div><span style=3D"color:#c586c0">if</span>=C2=A0(<span st=
yle=3D"color:#569cd6">auto</span>&amp;=C2=A0customer=C2=A0:=C2=A0get_<wbr>c=
ustomer(customer_id))=C2=A0{</div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">=
process</span>(customer);=C2=A0<span style=3D"color:#608b4e">//=C2=A0<wbr>c=
ustomer=C2=A0is=C2=A0a=C2=A0Customer&amp;=C2=A0and=C2=A0<wbr>not=C2=A0an=C2=
=A0optional.</span></div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:#608b4e">//=C2=A0We=C2=A0<wbr>can=C2=A0safely=
=C2=A0use=C2=A0customer=C2=A0as=C2=A0we=C2=A0<wbr>are=C2=A0guaranteed</span=
></div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:#608b4e">//=C2=A0to=C2=A0<wbr>have=C2=A0a=C2=
=A0valid=C2=A0reference=C2=A0and=C2=A0<wbr>that=C2=A0reference</span></div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<span style=3D"color:#608b4e">//=C2=A0<wbr>cannot=C2=A0extend=C2=
=A0beyond=C2=A0the `if` scope</span></div>
                <div>}</div>
                <div><span style=3D"color:#c586c0">else</span>=C2=A0{</div>
                <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">=
show_customer_not_found</span>();</div>
                <div>}</div>
              </div>
            </div>
          </div>
        </div>
        <div><br>
        </div>
        <div>As you can see, this feature is readable and addresses the
          indirection problem from earlier. =C2=A0Furthermore, it can be
          optimized easier for optional types and can theoretically work
          with any type, including user types, so long as they provide a
          conversion to boolean operator and a dereference operator. =C2=A0=
An
          example of how this could be interpreted follows:</div>
        <div><br>
        </div>
        <div>
          <div>
            <div><span style=3D"color:#608b4e">//=C2=A0New=C2=A0feature=C2=
=A0translates=C2=A0<wbr>into...=C2=A0//</span></div>
            <div><span style=3D"color:#569cd6">auto</span>=C2=A0_optional_c=
ustomer=C2=A0=3D=C2=A0get_<wbr>customer(customer_id);</div>
            <div><span style=3D"color:#c586c0">if</span>=C2=A0(_optional_cu=
stomer)=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#569cd6">auto=
</span>&amp;=C2=A0customer=C2=A0=3D=C2=A0*_<wbr>optional_customer;</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">proc=
ess</span>(customer);</div>
            <div>}</div>
            <div><span style=3D"color:#c586c0">else</span>=C2=A0{</div>
            <div>=C2=A0=C2=A0=C2=A0=C2=A0<span style=3D"color:#dcdcaa">show=
_customer_not_found</span>();</div>
            <div>}</div>
          </div>
        </div>
        <div><br>
        </div>
        <div>I&#39;m sure language features are not the easiest thing to
          add, and I&#39;m no compiler developer, but I&#39;m anxious to he=
ar
          any feedback you may have in regards to short comings,
          enhancements and overall complexity to implement. =C2=A0Thank you
          for considering this feature. - David Peterson</div>
      </div>
    </blockquote>
    The language based variant proposal [1] (I hope will be part of
    C++20) will allow to do pattern matching.<br>
    I believe this will be more adapted and will take in account
    std::expected as well.<br>
    <br>
    We could have something like<br>
    <br>
    <div><font color=3D"#3333ff">inspect</font>=C2=A0 (get_customer(custome=
r_id))=C2=A0{</div>
    <div>=C2=A0=C2=A0=C2=A0 just customer =3D&gt; =C2=A0=C2=A0 process(cust=
omer);</div>
    <div>=C2=A0=C2=A0=C2=A0 nothing =3D&gt;=C2=A0 show_customer_not_found()=
;</div>
    <div>}</div>
    <br>
    once std::optional would be adapted=C2=A0 to the patter matching
    constraints. <br>
    <br>
    Vicente<br>
    <br>
    [1]
    <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p009=
5r1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0095r1.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNGWwySL70JYd_tmx25229wqQ5LDJA&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0095r1.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNGWwySL70JYd_tmx25229wqQ5LDJA&#39;;return true;">http=
://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0095r1.html<=
/a><br>
  </div>

</blockquote></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/ebc016e5-db8a-43e0-adf6-0f4e592cec78%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ebc016e5-db8a-43e0-adf6-0f4e592cec78=
%40isocpp.org</a>.<br />

------=_Part_2099_1535902488.1493320432979--

------=_Part_2098_598995485.1493320432978--

.

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

On Thu, Apr 27, 2017 at 3:13 PM, Dan Raviv <dan.raviv@gmail.com> wrote:

> +1 for this.
> But even if we don't get language based variants, is there any good reason
> why optional<T> couldn't be implemented as a variant<nullopt_t, T> ? Which
> would solve the original issue brought up here by just allowing std::visit
> to be used.
>

I wish, but they have subtly different semantics, which makes things
annoying. Ideally those differences wouldn't exist, but here we are.

--
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/CANh8DEk_d0GN_5XWChdHPaZi41Tum5iGXbj%2BprxipvYgjFXBRA%40mail.gmail.com.

--f4030435be1497bbca054e2afd05
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 T=
hu, Apr 27, 2017 at 3:13 PM, Dan Raviv <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:dan.raviv@gmail.com" target=3D"_blank">dan.raviv@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">+1 for this.<d=
iv>But even if we don&#39;t get language based variants, is there any good =
reason why optional&lt;T&gt; couldn&#39;t be implemented as a variant&lt;nu=
llopt_t, T&gt; ? Which would solve the original issue brought up here by ju=
st allowing std::visit to be used.</div></div></blockquote><div><br></div><=
div>I wish, but they have subtly different semantics, which makes things an=
noying. Ideally those differences wouldn&#39;t exist, but here we are.</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/CANh8DEk_d0GN_5XWChdHPaZi41Tum5iGXbj%=
2BprxipvYgjFXBRA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk_d0GN_5=
XWChdHPaZi41Tum5iGXbj%2BprxipvYgjFXBRA%40mail.gmail.com</a>.<br />

--f4030435be1497bbca054e2afd05--

.

------=_Part_2039_864957844.1493321997285
Content-Type: multipart/alternative;
 boundary="----=_Part_2040_1422084029.1493321997286"

------=_Part_2040_1422084029.1493321997286
Content-Type: text/plain; charset=UTF-8



On Thursday, April 27, 2017 at 3:30:35 PM UTC-4, Matt Calabrese wrote:
>
> On Thu, Apr 27, 2017 at 3:13 PM, Dan Raviv <dan....@gmail.com
> <javascript:>> wrote:
>
>> +1 for this.
>> But even if we don't get language based variants, is there any good
>> reason why optional<T> couldn't be implemented as a variant<nullopt_t, T> ?
>> Which would solve the original issue brought up here by just allowing
>> std::visit to be used.
>>
>
> I wish, but they have subtly different semantics, which makes things
> annoying. Ideally those differences wouldn't exist, but here we are.
>

To expand on what Matt is no doubt eluding to, the basic problem with such
a thing (besides the interface) is that `optional` can provide an exception
guarantee with no overhead, while `variant` cannot in the general case.
Lots of ink and discussion time has been spilled over this issue, which
finally led to the current "not bad enough to keep arguing over" compromise
`std::variant` version.

But the compromise puts us in a place where `optional<T>` provides a
different exception guarantee than `variant<nullopt, T>`. If assignment or
emplacement of `optional<T>` fails, then we know that it has no value.
Whereas `variant<nullopt, T>` gets (possibly) put into the
"valueless_by_exception"-state.

--
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/25857aa7-9e21-408a-bc34-2d844d33d2de%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, April 27, 2017 at 3:30:35 PM UTC-4, M=
att Calabrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Apr 27, 2017 at 3:13 PM, D=
an Raviv <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"2QWmeFBpAQAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">dan....@gmail.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">+1 for this.<div>But even if we d=
on&#39;t get language based variants, is there any good reason why optional=
&lt;T&gt; couldn&#39;t be implemented as a variant&lt;nullopt_t, T&gt; ? Wh=
ich would solve the original issue brought up here by just allowing std::vi=
sit to be used.</div></div></blockquote><div><br></div><div>I wish, but the=
y have subtly different semantics, which makes things annoying. Ideally tho=
se differences wouldn&#39;t exist, but here we are.</div></div></div></div>=
</blockquote><div><br>To expand on what Matt is no doubt eluding to, the ba=
sic problem with such a thing (besides the interface) is that `optional` ca=
n provide an exception guarantee with no overhead, while `variant` cannot i=
n the general case. Lots of ink and discussion time has been spilled over t=
his issue, which finally led to the current &quot;not bad enough to keep ar=
guing over&quot; compromise `std::variant` version.<br><br>But the compromi=
se puts us in a place where `optional&lt;T&gt;` provides a different except=
ion guarantee than `variant&lt;nullopt, T&gt;`. If assignment or emplacemen=
t of `optional&lt;T&gt;` fails, then we know that it has no value. Whereas =
`variant&lt;nullopt, T&gt;` gets (possibly) put into the &quot;valueless_by=
_exception&quot;-state.<br></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/25857aa7-9e21-408a-bc34-2d844d33d2de%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25857aa7-9e21-408a-bc34-2d844d33d2de=
%40isocpp.org</a>.<br />

------=_Part_2040_1422084029.1493321997286--

------=_Part_2039_864957844.1493321997285--

.

------=_Part_5516_1920585370.1493322461231
Content-Type: multipart/alternative;
 boundary="----=_Part_5517_1058381775.1493322461232"

------=_Part_5517_1058381775.1493322461232
Content-Type: text/plain; charset=UTF-8

Ah yes, the lovely "valueless_by_exception" state :)
Thanks for the explanation!

I guess the original issue brought up in the thread could still be solved
relatively nicely just by adding a method to std::optional<T> similar to
what std::visit does for variants. This (templated on Ret) method could
just accept two std::function parameters: one std::function<Ret(T)> and one
std::function<Ret()>, where the right function would be called according to
whether the optional has a value or not.

Cheers,
Dan


On Thursday, April 27, 2017 at 9:39:57 PM UTC+2, Nicol Bolas wrote:
>
>
>
> On Thursday, April 27, 2017 at 3:30:35 PM UTC-4, Matt Calabrese wrote:
>>
>> On Thu, Apr 27, 2017 at 3:13 PM, Dan Raviv <dan....@gmail.com> wrote:
>>
>>> +1 for this.
>>> But even if we don't get language based variants, is there any good
>>> reason why optional<T> couldn't be implemented as a variant<nullopt_t, T> ?
>>> Which would solve the original issue brought up here by just allowing
>>> std::visit to be used.
>>>
>>
>> I wish, but they have subtly different semantics, which makes things
>> annoying. Ideally those differences wouldn't exist, but here we are.
>>
>
> To expand on what Matt is no doubt eluding to, the basic problem with such
> a thing (besides the interface) is that `optional` can provide an exception
> guarantee with no overhead, while `variant` cannot in the general case.
> Lots of ink and discussion time has been spilled over this issue, which
> finally led to the current "not bad enough to keep arguing over" compromise
> `std::variant` version.
>
> But the compromise puts us in a place where `optional<T>` provides a
> different exception guarantee than `variant<nullopt, T>`. If assignment or
> emplacement of `optional<T>` fails, then we know that it has no value.
> Whereas `variant<nullopt, T>` gets (possibly) put into the
> "valueless_by_exception"-state.
>

--
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/87a5d3f7-82ba-4b26-8408-ae69dd377ac9%40isocpp.org.

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

<div dir=3D"ltr">Ah yes, the lovely &quot;valueless_by_exception&quot; stat=
e :)<div>Thanks for the explanation!</div><div><br></div><div>I guess the o=
riginal issue brought up in the thread could still be solved relatively nic=
ely just by adding a method to std::optional&lt;T&gt; similar to what std::=
visit does for variants. This (templated on Ret) method could just accept t=
wo std::function parameters: one std::function&lt;Ret(T)&gt; and one std::f=
unction&lt;Ret()&gt;, where the right function would be called according to=
 whether the optional has a value or not.</div><div><br></div><div>Cheers,<=
/div><div>Dan<br><div><br><br>On Thursday, April 27, 2017 at 9:39:57 PM UTC=
+2, Nicol Bolas 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"><br><br>On Thursday, April 27, 2017 at 3:30:35 PM UTC-4, Matt Cala=
brese 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><=
div class=3D"gmail_quote">On Thu, Apr 27, 2017 at 3:13 PM, Dan Raviv <span =
dir=3D"ltr">&lt;<a rel=3D"nofollow">dan....@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">+1 for this.<div>But ev=
en if we don&#39;t get language based variants, is there any good reason wh=
y optional&lt;T&gt; couldn&#39;t be implemented as a variant&lt;nullopt_t, =
T&gt; ? Which would solve the original issue brought up here by just allowi=
ng std::visit to be used.</div></div></blockquote><div><br></div><div>I wis=
h, but they have subtly different semantics, which makes things annoying. I=
deally those differences wouldn&#39;t exist, but here we are.</div></div></=
div></div></blockquote><div><br>To expand on what Matt is no doubt eluding =
to, the basic problem with such a thing (besides the interface) is that `op=
tional` can provide an exception guarantee with no overhead, while `variant=
` cannot in the general case. Lots of ink and discussion time has been spil=
led over this issue, which finally led to the current &quot;not bad enough =
to keep arguing over&quot; compromise `std::variant` version.<br><br>But th=
e compromise puts us in a place where `optional&lt;T&gt;` provides a differ=
ent exception guarantee than `variant&lt;nullopt, T&gt;`. If assignment or =
emplacement of `optional&lt;T&gt;` fails, then we know that it has no value=
.. Whereas `variant&lt;nullopt, T&gt;` gets (possibly) put into the &quot;va=
lueless_by_exception&quot;-<wbr>state.<br></div></div></blockquote></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/87a5d3f7-82ba-4b26-8408-ae69dd377ac9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/87a5d3f7-82ba-4b26-8408-ae69dd377ac9=
%40isocpp.org</a>.<br />

------=_Part_5517_1058381775.1493322461232--

------=_Part_5516_1920585370.1493322461231--

.

This is a multi-part message in MIME format.
--------------CB677B2A24D96C70AFDC6775
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 27/04/2017 =C3=A0 21:47, Dan Raviv a =C3=A9crit :
> Ah yes, the lovely "valueless_by_exception" state :)
> Thanks for the explanation!
>
> I guess the original issue brought up in the thread could still be=20
> solved relatively nicely just by adding a method to std::optional<T>=20
> similar to what std::visit does for variants. This (templated on Ret)=20
> method could just accept two std::function parameters: one=20
> std::function<Ret(T)> and one std::function<Ret()>, where the right=20
> function would be called according to whether the optional has a value=20
> or not.
>
> Cheers,
> Dan
>
>
> On Thursday, April 27, 2017 at 9:39:57 PM UTC+2, Nicol Bolas wrote:
>
>
>
>     On Thursday, April 27, 2017 at 3:30:35 PM UTC-4, Matt Calabrese
>     wrote:
>
>         On Thu, Apr 27, 2017 at 3:13 PM, Dan Raviv <dan....@gmail.com>
>         wrote:
>
>             +1 for this.
>             But even if we don't get language based variants, is there
>             any good reason why optional<T> couldn't be implemented as
>             a variant<nullopt_t, T> ? Which would solve the original
>             issue brought up here by just allowing std::visit to be used.
>
>
>         I wish, but they have subtly different semantics, which makes
>         things annoying. Ideally those differences wouldn't exist, but
>         here we are.
>
>
>     To expand on what Matt is no doubt eluding to, the basic problem
>     with such a thing (besides the interface) is that `optional` can
>     provide an exception guarantee with no overhead, while `variant`
>     cannot in the general case. Lots of ink and discussion time has
>     been spilled over this issue, which finally led to the current
>     "not bad enough to keep arguing over" compromise `std::variant`
>     version.
>
>     But the compromise puts us in a place where `optional<T>` provides
>     a different exception guarantee than `variant<nullopt, T>`. If
>     assignment or emplacement of `optional<T>` fails, then we know
>     that it has no value. Whereas `variant<nullopt, T>` gets
>     (possibly) put into the "valueless_by_exception"-state.
>

I proposed a match function [1] that should works with multiple=20
variants, optionals, expected or any sum type. It is inline with the=20
languages based inspect statement and BTW, the proposal had a inspect=20
function also. At the time there were too much work around variant and=20
we needed a something consensual.

I'm reworking this proposal to define once for all a SumType concept and=20
function that work with them, in particular match [2].
I'm not sure the proposal will be ready for Toronto. The way I'm=20
customizing all this concepts needs a paper that I'm sure will not be=20
consensual :( on an alternative way to customize in the standard. I did=20
a presentation in code:dive about this subject last fall [3]. Any=20
feedback in a separated thread is welcome.

Vicente

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0050r0.pdf
[2]=20
https://github.com/viboes/std-make/tree/master/include/experimental/fundame=
ntal/v3/sum_type
[3]=20
https://cdn2-ecros.pl/event/codedive/files/presentations/2016/TraitsAsCusto=
mizationPoints.pdf=20
and https://www.youtube.com/watch?v=3DDsm12yd637E



--=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/3ae41f30-83e0-1a69-1eb4-f435f4df4a27%40wanadoo.f=
r.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 27/04/2017 =C3=A0 21:47, Dan Raviv a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:87a5d3f7-82ba-4b26-8408-ae69dd377ac9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Ah yes, the lovely "valueless_by_exception" state
        :)
        <div>Thanks for the explanation!</div>
        <div><br>
        </div>
        <div>I guess the original issue brought up in the thread could
          still be solved relatively nicely just by adding a method to
          std::optional&lt;T&gt; similar to what std::visit does for
          variants. This (templated on Ret) method could just accept two
          std::function parameters: one std::function&lt;Ret(T)&gt; and
          one std::function&lt;Ret()&gt;, where the right function would
          be called according to whether the optional has a value or
          not.</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Dan<br>
          <div><br>
            <br>
            On Thursday, April 27, 2017 at 9:39:57 PM UTC+2, Nicol Bolas
            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"><br>
                <br>
                On Thursday, April 27, 2017 at 3:30:35 PM UTC-4, Matt
                Calabrese 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>
                      <div class=3D"gmail_quote">On Thu, Apr 27, 2017 at
                        3:13 PM, Dan Raviv <span dir=3D"ltr">&lt;<a
                            moz-do-not-send=3D"true" rel=3D"nofollow">dan..=
...@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">+1 for this.
                            <div>But even if we don't get language based
                              variants, is there any good reason why
                              optional&lt;T&gt; couldn't be implemented
                              as a variant&lt;nullopt_t, T&gt; ? Which
                              would solve the original issue brought up
                              here by just allowing std::visit to be
                              used.</div>
                          </div>
                        </blockquote>
                        <div><br>
                        </div>
                        <div>I wish, but they have subtly different
                          semantics, which makes things annoying.
                          Ideally those differences wouldn't exist, but
                          here we are.</div>
                      </div>
                    </div>
                  </div>
                </blockquote>
                <div><br>
                  To expand on what Matt is no doubt eluding to, the
                  basic problem with such a thing (besides the
                  interface) is that `optional` can provide an exception
                  guarantee with no overhead, while `variant` cannot in
                  the general case. Lots of ink and discussion time has
                  been spilled over this issue, which finally led to the
                  current "not bad enough to keep arguing over"
                  compromise `std::variant` version.<br>
                  <br>
                  But the compromise puts us in a place where
                  `optional&lt;T&gt;` provides a different exception
                  guarantee than `variant&lt;nullopt, T&gt;`. If
                  assignment or emplacement of `optional&lt;T&gt;`
                  fails, then we know that it has no value. Whereas
                  `variant&lt;nullopt, T&gt;` gets (possibly) put into
                  the "valueless_by_exception"-<wbr>state.<br>
                </div>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    I proposed a match function [1] that should works with multiple
    variants, optionals, expected or any sum type. It is inline with the
    languages based inspect statement and BTW, the proposal had a
    inspect function also. At the time there were too much work around
    variant and we needed a something consensual.<br>
    <br>
    I'm reworking this proposal to define once for all a SumType concept
    and function that work with them, in particular match [2].<br>
    I'm not sure the proposal will be ready for Toronto. The way I'm
    customizing all this concepts needs a paper that I'm sure will not
    be consensual :( on an alternative way to customize in the standard.
    I did a presentation in code:dive about this subject last fall [3].
    Any feedback in a separated thread is welcome.<br>
    <br>
    Vicente <br>
    <br>
    [1]
    <a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2015/p0050r0.pdf">http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2015/p0050r0.pdf</a><br>
    [2]
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes/std-ma=
ke/tree/master/include/experimental/fundamental/v3/sum_type">https://github=
..com/viboes/std-make/tree/master/include/experimental/fundamental/v3/sum_ty=
pe</a><br>
    [3]
<a class=3D"moz-txt-link-freetext" href=3D"https://cdn2-ecros.pl/event/code=
dive/files/presentations/2016/TraitsAsCustomizationPoints.pdf">https://cdn2=
-ecros.pl/event/codedive/files/presentations/2016/TraitsAsCustomizationPoin=
ts.pdf</a>
    and <a class=3D"moz-txt-link-freetext" href=3D"https://www.youtube.com/=
watch?v=3DDsm12yd637E">https://www.youtube.com/watch?v=3DDsm12yd637E</a>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
    <h3 class=3D"r"><br>
    </h3>
  </body>
</html>

<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/3ae41f30-83e0-1a69-1eb4-f435f4df4a27%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3ae41f30-83e0-1a69-1eb4-f435f4df4a27=
%40wanadoo.fr</a>.<br />

--------------CB677B2A24D96C70AFDC6775--

.