220 21817 article Path: news.gmane.org!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0099 Suggestion: Comparable execution_contexts Date: Thu, 15 Oct 2015 13:28:04 -0700 Lines: 94 Approved: news@gmane.org Message-ID: References: <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/alternative; boundary=001a1137bdd020ba5b05222a845e X-Trace: ger.gmane.org 1444940893 2925 80.91.229.3 (15 Oct 2015 20:28:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 20:28:13 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBVEYQCYQKGQE52TAXEY@isocpp.org Thu Oct 15 22:28:12 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zmp8E-0005w2-Hq for gclcip-std-proposals@m.gmane.org; Thu, 15 Oct 2015 22:28:10 +0200 Original-Received: by pabws5 with SMTP id ws5sf3329296pab.3 for ; Thu, 15 Oct 2015 13:28:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=u1BR01LLY2gicD7ZIAG5wko656GnF5uokldNgdviOKI=; b=AY4MueBqdT2gTDHSopnCDRFG5sa9eZFRpdk7MO60vnytJBqhEmTYOM3kbYf83z4U/y oLRXjNr2T8mo3K5OUnqeqLtydvcr49iPpT0XjW4pwzxnrQQBnLbQVcVTVUMn1w+rayza dDYVOG0RkGGNUWMmQKUzjuVrctxb731qD+/M5yh+eCeyKtDRxLzfQSPqkDOrVR3dycJ7 9jCuIxQfWIHLG1y+ck6lCjlt9o91UjBOrb2N/zxusRt/tz3ip98P6TeIXsXcOKCqs3xR uBqyyGt7HN5Rz9xgdhj7cqzbizhbCRvtdfM2YAB0IMnGG22sFUGVRb+be9Ete7QEwtMI 75Dw== X-Gm-Message-State: ALoCoQk6AOSncblz4quL1/WU15WqCED4EYR9eYbWepyUBi/8cMIQmKssNiF939VV7FuoWrHkQp1t X-Received: by 10.66.132.69 with SMTP id os5mr9196566pab.12.1444940889056; Thu, 15 Oct 2015 13:28:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.251.198 with SMTP id zm6ls448834obc.33.gmail; Thu, 15 Oct 2015 13:28:04 -0700 (PDT) X-Received: by 10.60.150.243 with SMTP id ul19mr6962642oeb.64.1444940884521; Thu, 15 Oct 2015 13:28:04 -0700 (PDT) Original-Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com. [2607:f8b0:4003:c06::236]) by mx.google.com with ESMTPS id pg15si8410407oeb.17.2015.10.15.13.28.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 13:28:04 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::236 as permitted sender) client-ip=2607:f8b0:4003:c06::236; Original-Received: by oiev17 with SMTP id v17so5488198oie.2 for ; Thu, 15 Oct 2015 13:28:04 -0700 (PDT) X-Received: by 10.202.77.138 with SMTP id a132mr6874341oib.55.1444940884243; Thu, 15 Oct 2015 13:28:04 -0700 (PDT) Original-Received: by 10.60.93.37 with HTTP; Thu, 15 Oct 2015 13:28:04 -0700 (PDT) In-Reply-To: <850904d9-b894-4ff5-b0a3-79a7cbcfa896@isocpp.org> X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::236 as permitted sender) smtp.mailfrom=calabrese@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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: , X-Original-From: Matt Calabrese Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21817 Archived-At: --001a1137bdd020ba5b05222a845e Content-Type: text/plain; charset=UTF-8 On Thu, Oct 15, 2015 at 9:56 AM, Nicol Bolas 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
On T= hu, Oct 15, 2015 at 9:56 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
In P0099, an `execution_co= ntext` represents a reference (counted, hopefully atomically) to a callstac= k+stuff needed for a suspended callstack. That's great and all. But the= re is one thing missing: the ability to compare them.

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

The general gist is that `operator=3D=3D` i= s true only if both objects reference the same context. `operator<` 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).
Speaking of which, hashing would be useful for them as well, for the afore= mentioned `unordered_set`.

+1 to = all of these, though possibly just std::less rather than operator < (I d= on'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 (y= ou can always explicitly provide comparators to standard containers and alg= orithms). Regardless, they should be provided.

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

--

---
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>.
--001a1137bdd020ba5b05222a845e-- .