------=_Part_770_1794568796.1444928214276
Content-Type: multipart/alternative;
 boundary="----=_Part_771_1613127962.1444928214277"

------=_Part_771_1613127962.1444928214277
Content-Type: text/plain; charset=UTF-8

In P0099, an `execution_context` represents a reference (counted, hopefully
atomically) to a callstack+stuff needed for a suspended callstack. That's
great and all. But there is one thing missing: the ability to compare them.

There is no operator== or operator< defined for them. So you can't build a
`(flat_)set` out of them, to prevent someone from accidentally putting the
same context into it twice. You also can't build an `unordered_set` of
them. It would also be useful to build a `(flat_)map` of them, using the
`execution_context` as a key.

The general gist is that `operator==` is true only if both objects
reference the same context. `operator<` creates an entirely arbitrary
ordering of them, which is entirely stable within an execution (similar to
the wording of the Hash concept in C++14).

Speaking of which, hashing would be useful for them as well, for the
aforementioned `unordered_set`.

It should be noted that without direct support for these operations, it
would be very difficult to build such things as a layer on top of them.

This is similar to my previous idea about being able to convert them into a
pointer, but I think this is rather more useful than just that. The pointer
conversion would allow one to implement all of these features, but by
implementing the features directly, they're guaranteed to exist, so
abstractions can be built atop them.

The higher level features also don't rely on dealing with `void*`, allowing
implementations the freedom to implement them however they see fit.

--

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

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

<div dir=3D"ltr">In P0099, an `execution_context` represents a reference (c=
ounted, hopefully atomically) to a callstack+stuff needed for a suspended c=
allstack. That&#39;s great and all. But there is one thing missing: the abi=
lity to compare them.<br><br>There is no operator=3D=3D or operator&lt; def=
ined for them. So you can&#39;t build a `(flat_)set` out of them, to preven=
t someone from accidentally putting the same context into it twice. You als=
o can&#39;t build an `unordered_set` of them. It would also be useful to bu=
ild a `(flat_)map` of them, using the `execution_context` as a key.<br><br>=
The general gist is that `operator=3D=3D` is true only if both objects refe=
rence the same context. `operator&lt;` creates an entirely arbitrary orderi=
ng of them, which is entirely stable within an execution (similar to the wo=
rding of the Hash concept in C++14).<br><br>Speaking of which, hashing woul=
d be useful for them as well, for the aforementioned `unordered_set`.<br><b=
r>It should be noted that without direct support for these operations, it w=
ould be very difficult to build such things as a layer on top of them.<br><=
br>This is similar to my previous idea about being able to convert them int=
o a pointer, but I think this is rather more useful than just that. The poi=
nter conversion would allow one to implement all of these features, but by =
implementing the features directly, they&#39;re guaranteed to exist, so abs=
tractions can be built atop them.<br><br>The higher level features also don=
&#39;t rely on dealing with `void*`, allowing implementations the freedom t=
o implement them however they see fit.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_771_1613127962.1444928214277--
------=_Part_770_1794568796.1444928214276--

.

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

On Thu, Oct 15, 2015 at 9:56 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> In P0099, an `execution_context` represents a reference (counted,
> hopefully atomically) to a callstack+stuff needed for a suspended
> callstack. That's great and all. But there is one thing missing: the
> ability to compare them.
>
> There is no operator== or operator< defined for them. So you can't build a
> `(flat_)set` out of them, to prevent someone from accidentally putting the
> same context into it twice. You also can't build an `unordered_set` of
> them. It would also be useful to build a `(flat_)map` of them, using the
> `execution_context` as a key.
>
> The general gist is that `operator==` is true only if both objects
> reference the same context. `operator<` creates an entirely arbitrary
> ordering of them, which is entirely stable within an execution (similar to
> the wording of the Hash concept in C++14).
>
> Speaking of which, hashing would be useful for them as well, for the
> aforementioned `unordered_set`.
>

+1 to all of these, though possibly just std::less rather than operator <
(I don't have strong opinions on that either way, but I know that a lot of
people do). Not having these doesn't make them *strictly* unusable with
those datastructures, though, it just makes them easier to be used (you can
always explicitly provide comparators to standard containers and
algorithms). Regardless, they should be provided.

IMO, these operations should be provided for all standard library object
types, but that's also a somewhat more controversial view.

--

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

--001a1137bdd020ba5b05222a845e
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, Oct 15, 2015 at 9:56 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">In P0099, an `execution_co=
ntext` represents a reference (counted, hopefully atomically) to a callstac=
k+stuff needed for a suspended callstack. That&#39;s great and all. But the=
re is one thing missing: the ability to compare them.<br><br>There is no op=
erator=3D=3D or operator&lt; defined for them. So you can&#39;t build a `(f=
lat_)set` out of them, to prevent someone from accidentally putting the sam=
e context into it twice. You also can&#39;t build an `unordered_set` of the=
m. It would also be useful to build a `(flat_)map` of them, using the `exec=
ution_context` as a key.<br><br>The general gist is that `operator=3D=3D` i=
s true only if both objects reference the same context. `operator&lt;` crea=
tes an entirely arbitrary ordering of them, which is entirely stable within=
 an execution (similar to the wording of the Hash concept in C++14).<br><br=
>Speaking of which, hashing would be useful for them as well, for the afore=
mentioned `unordered_set`.<br></div></blockquote><div><br></div><div>+1 to =
all of these, though possibly just std::less rather than operator &lt; (I d=
on&#39;t have strong opinions on that either way, but I know that a lot of =
people do). Not having these doesn&#39;t make them <i>strictly</i> unusable=
 with those datastructures, though, it just makes them easier to be used (y=
ou can always explicitly provide comparators to standard containers and alg=
orithms). Regardless, they should be provided.<br></div><div><br></div><div=
>IMO, these operations should be provided for all standard library object t=
ypes, but that&#39;s also a somewhat more controversial view.</div></div></=
div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1137bdd020ba5b05222a845e--

.

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

On 15 October 2015 at 15:28, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> +1 to all of these, though possibly just std::less rather than operator <
> (I don't have strong opinions on that either way, but I know that a lot of
> people do).
>

+1 to comparison ops, -10000 to just std::less.

Nothing in the standard specializes std::less*.  You do not want to open
that can of worms.  For instance, the discussion around comparison ops is a
major reason optional didn't make it into C++14.  If LEWG wishes to open
that discussion, they will.  If you wish to open it, be prepared to not get
comparable execution contexts because of it.

*Yeah, there is are weasel words for hardware with pointers that are not
totally ordered.  Until such a beast exists that isn't so ancient that it
actually has a C++11 compiler or better generating code for it, that hook
is indistinguishable from non-existent.  IMNSHO, of course.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On 15 October 2015 at 15:28, &#39;Matt Calabrese&#39; via =
ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto=
:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>+1 to all of these, though possibly just std::less rather =
than operator &lt; (I don&#39;t have strong opinions on that either way, bu=
t I know that a lot of people do).</div></div></div></div></blockquote><div=
><br></div><div>+1 to comparison ops, -10000 to just std::less.</div><div><=
br></div><div>Nothing in the standard specializes std::less*.=C2=A0 You do =
not want to open that can of worms.=C2=A0 For instance, the discussion arou=
nd comparison ops is a major reason optional didn&#39;t make it into C++14.=
=C2=A0 If LEWG wishes to open that discussion, they will.=C2=A0 If you wish=
 to open it, be prepared to not get comparable execution contexts because o=
f it.</div><div><br></div><div>*Yeah, there is are weasel words for hardwar=
e with pointers that are not totally ordered.=C2=A0 Until such a beast exis=
ts that isn&#39;t so ancient that it actually has a C++11 compiler or bette=
r generating code for it, that hook is indistinguishable from non-existent.=
=C2=A0 IMNSHO, of course.</div></div>-- <br><div class=3D"gmail_signature">=
=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 (8=
47) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1143f1c07d813105222b0c3f--

.

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

On Thu, Oct 15, 2015 at 2:05 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 15 October 2015 at 15:28, 'Matt Calabrese' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> +1 to all of these, though possibly just std::less rather than operator <
>> (I don't have strong opinions on that either way, but I know that a lot of
>> people do).
>>
>
> +1 to comparison ops, -10000 to just std::less.
>
> Nothing in the standard specializes std::less*.  You do not want to open
> that can of worms.  For instance, the discussion around comparison ops is a
> major reason optional didn't make it into C++14.  If LEWG wishes to open
> that discussion, they will.  If you wish to open it, be prepared to not get
> comparable execution contexts because of it.
>

Agreed. I'm in favor of operator <, I'm mostly just pointing out that there
*is* a can of worms there, and people may be waiting on the side-lines with
can openers ;)

--

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

--001a1142e6480849a405222b1f38
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, Oct 15, 2015 at 2:05 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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"><span =
class=3D"">On 15 October 2015 at 15:28, &#39;Matt Calabrese&#39; via ISO C+=
+ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-p=
roposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</sp=
an> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><div>+1 to all of these, though possibly just=
 std::less rather than operator &lt; (I don&#39;t have strong opinions on t=
hat either way, but I know that a lot of people do).</div></div></div></div=
></blockquote><div><br></div></span><div>+1 to comparison ops, -10000 to ju=
st std::less.</div><div><br></div><div>Nothing in the standard specializes =
std::less*.=C2=A0 You do not want to open that can of worms.=C2=A0 For inst=
ance, the discussion around comparison ops is a major reason optional didn&=
#39;t make it into C++14.=C2=A0 If LEWG wishes to open that discussion, the=
y will.=C2=A0 If you wish to open it, be prepared to not get comparable exe=
cution contexts because of it.</div></div></div></div></blockquote><div><br=
></div><div>Agreed. I&#39;m in favor of operator &lt;, I&#39;m mostly just =
pointing out that there <i>is</i> a can of worms there, and people may be w=
aiting on the side-lines with can openers ;)</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1142e6480849a405222b1f38--

.