220 21812 <850904d9-b894-4ff5-b0a3-79a7cbcfa896@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: P0099 Suggestion: Comparable execution_contexts Date: Thu, 15 Oct 2015 09:56:54 -0700 (PDT) Lines: 91 Approved: news@gmane.org Message-ID: <850904d9-b894-4ff5-b0a3-79a7cbcfa896@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_770_1794568796.1444928214276" X-Trace: ger.gmane.org 1444928228 21443 80.91.229.3 (15 Oct 2015 16:57:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 16:57:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBV5V76YAKGQEOW6TKOA@isocpp.org Thu Oct 15 18:57:02 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zmlpr-0008C1-PM for gclcip-std-proposals@m.gmane.org; Thu, 15 Oct 2015 18:56:59 +0200 Original-Received: by vkaw128 with SMTP id w128sf35198085vka.2 for ; Thu, 15 Oct 2015 09:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ySft4AJJLZAKIfz7xClr3KMIKQ3Awa6Hwr5fu9BVhAw=; b=Asul3LdiTKk8ezHJ023Km+bnFMebg3tM4Z5q6ri9Afif4Vh5HF3rOfx5+yUoxp+i56 NEAF8me2joItkdLed6jiG72XN19GYvi7BnNqhLyjKcFVymqNhgIfFcZaQ5quq9c265rk hfzi9ULif5NQJUjRZDyrcxaU7FxGLbfs0ikW7FdEesw4mUBWAx1ewgiv37K1tnErlh9F 0SQejw/azHwSzpInPsPpo4ElOM+WQ0YDyLUwGpd80H0v+mUstPDwHPr3E243zrY6PYAa pG9Aw/QLkXrHb49c2EqvLzqFwfyvBe1qysbeotVGyXFGMrwekqLJ6X45/U+YPV+4pMYJ zqhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ySft4AJJLZAKIfz7xClr3KMIKQ3Awa6Hwr5fu9BVhAw=; b=kpeLuv30jOU5B9Xpha/7Ek/7d2MkAtGjgDINtVLAMgQO1hlbzPLvYjAcGss12NwsZP O/X2DbGf3ewf5JVov/b4r39GHF9KMXUhXfaRUKzIpEMAh7Ow/WcmPlY49GDe8WnJwE2E XgPMrs2VxvRZFovWXIagFyaUWZFsx0z1eEghHMpMP/poZjli1tT8OznGADr0hJmJinRl 4LA8F9GpHUVUcz3FsJta8mkk7hS4EcnAVCIfEP24q1Eqb8gvPhLkvbXeBz6owPHALChr RlT0j2Xqv5zSRP9XeK+zusBTYPwMW3O8B6AI+bIDvxs7MRTJMm3vBpamlYHydsG9CoFV SZ6Q== X-Gm-Message-State: ALoCoQnvJV3qY+8qWXi8pqfdtJAkeHfIH8zzeVUt/c+OemxfYxXstWRyIUqZRaEMuJcO2c8R3yQ4 X-Received: by 10.13.235.198 with SMTP id u189mr977581ywe.54.1444928218864; Thu, 15 Oct 2015 09:56:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.88.73 with SMTP id be9ls2088120igb.28.canary; Thu, 15 Oct 2015 09:56:54 -0700 (PDT) X-Received: by 10.50.109.166 with SMTP id ht6mr530485igb.0.1444928214825; Thu, 15 Oct 2015 09:56:54 -0700 (PDT) X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21812 Archived-At: ------=_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
In P0099, an `execution_context` represents a reference (c= ounted, hopefully atomically) to a callstack+stuff needed for a suspended c= allstack. That's great and all. But there is one thing missing: the abi= lity to compare them.

There is no operator=3D=3D or operator< def= ined for them. So you can'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'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.

= The general gist is that `operator=3D=3D` is true only if both objects refe= rence the same context. `operator<` 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).

Speaking of which, hashing woul= d be useful for them as well, for the aforementioned `unordered_set`.
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>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're guaranteed to exist, so abs= tractions can be built atop them.

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

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_771_1613127962.1444928214277-- ------=_Part_770_1794568796.1444928214276-- .