220 21298 article Path: news.gmane.org!not-for-mail From: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: missing hash_code result in P0029 Date: Mon, 5 Oct 2015 09:17:45 -0700 Lines: 96 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114786f08e9fd705215ddad1 X-Trace: ger.gmane.org 1444061871 16474 80.91.229.3 (5 Oct 2015 16:17:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 16:17:51 +0000 (UTC) Cc: "ISO C++ Standard - Future Proposals" , Chandler Carruth To: Sean Middleditch Original-X-From: std-proposals+bncBD74DCN5SYHBBKWFZKYAKGQEEDVLIZA@isocpp.org Mon Oct 05 18:17:50 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zj8ST-0005eO-S1 for gclcip-std-proposals@m.gmane.org; Mon, 05 Oct 2015 18:17:50 +0200 Original-Received: by igcxw12 with SMTP id xw12sf199729812igc.0 for ; Mon, 05 Oct 2015 09:17:48 -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:cc: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=09g7DkMTT2glmCXBK/YcCJ5+Hgag7tg/43aWZ7geEFw=; b=MKkUm3lOcMaZyD20EX9orCJY2DGabFUyHsiZcfyGg10ps+EAIpG/WUq39ujkDCn3V/ mykElze9WDTAyo4G258YXxf73WLLFOtxRw7ZwMAlMtsZyOjVvPIb/gvPv+NZwVaJXkAU kmNRyLHWpDHddPBUdMCzN7zueVHCrAXqf3skwSu0cB3zWObt5vwUTtYQAll87bfHYGXd 2N/DE1ktVoDRvfmcGx567cyOgrZXNtLxYkvQvZG3VuyELQRb8GRNfyKAwFO/9DTvvDn/ dt+g3ydtI7gNBcXJwS8xBM0HB3qfUBwK8kMcP7m15L7vLXFsNBJWlrETR0uwvhCzAfAt UGlQ== X-Gm-Message-State: ALoCoQnTprk1u6CJQdXKgfFGPyAc6jL02Hn/gcj7iGfj/Mel46OttLXfkYw4EiZofSeTl3t/qmn2 X-Received: by 10.107.160.72 with SMTP id j69mr27131648ioe.7.1444061868693; Mon, 05 Oct 2015 09:17:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.41.136 with SMTP id z8ls3348391qgz.37.gmail; Mon, 05 Oct 2015 09:17:46 -0700 (PDT) X-Received: by 10.31.11.209 with SMTP id 200mr15272174vkl.84.1444061866264; Mon, 05 Oct 2015 09:17:46 -0700 (PDT) Original-Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com. [2607:f8b0:400c:c05::22a]) by mx.google.com with ESMTPS id h196si14240527vkh.102.2015.10.05.09.17.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2015 09:17:46 -0700 (PDT) Received-SPF: pass (google.com: domain of gromer@google.com designates 2607:f8b0:400c:c05::22a as permitted sender) client-ip=2607:f8b0:400c:c05::22a; Original-Received: by vkat63 with SMTP id t63so99552732vka.1 for ; Mon, 05 Oct 2015 09:17:46 -0700 (PDT) X-Received: by 10.31.107.213 with SMTP id k82mr21013462vki.5.1444061865985; Mon, 05 Oct 2015 09:17:45 -0700 (PDT) Original-Received: by 10.103.66.198 with HTTP; Mon, 5 Oct 2015 09:17:45 -0700 (PDT) In-Reply-To: X-Original-Sender: gromer@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gromer@google.com designates 2607:f8b0:400c:c05::22a as permitted sender) smtp.mailfrom=gromer@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: Geoffrey Romer Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21298 Archived-At: --001a114786f08e9fd705215ddad1 Content-Type: text/plain; charset=UTF-8 The API for extracting a hash value, and symmetrically the API for initializing the HashCode, is deliberately left unspecified. In the case of std::hash_code it doesn't matter, because only std::hash needs to be aware of those details. Other HashCode types can provide similar functor wrappers, or explicitly specify those APIs however they choose. The initialization API is unspecified because it depends on the implementation details of the HashCode (e.g. hashing::farmhash needs a pointer to its state as an input). The value-extraction API is unspecified because it's unsafe: in many cases it will leave the HashCode in an unusable state. I solved that in the prototype by making it rvalue-ref qualified, but then I realized there's no need to specify it at all (particularly when the initialization API is also unspecified), and an unspecified API is simpler, safer, and harder to bikeshed. I had thought I spelled this out in the paper somewhere, but I can't immediately find it, so that may be an oversight on my part. On Sat, Oct 3, 2015 at 8:25 PM, Sean Middleditch wrote: > Unless I'm missing something (wouldn't surprise me), there's no way > specific in the paper for user code to extract the resulting hash from > hash_code or the HashCode concept. > > The sample implementation code has a member result_type alias and an > `operator result_type()` but those interfaces are not present in the paper. > > Seems like a small but rather critical missing piece. :) > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html > -- --- 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/. --001a114786f08e9fd705215ddad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The API for extracting a hash value, and symmetrically the= API for initializing the HashCode, is deliberately left unspecified. In th= e case of std::hash_code it doesn't matter, because only std::hash need= s to be aware of those details. Other HashCode types can provide similar fu= nctor wrappers, or explicitly specify those APIs however they choose.
<= br>
The initialization API is unspecified because it depends on t= he implementation details of the HashCode (e.g. hashing::farmhash needs a p= ointer to its state as an input). The value-extraction API is unspecified b= ecause it's unsafe: in many cases it will leave the HashCode in an unus= able state. I solved that in the prototype by making it rvalue-ref qualifie= d, but then I realized there's no need to specify it at all (particular= ly when the initialization API is also unspecified), and an unspecified API= is simpler, safer, and harder to bikeshed.

I had = thought I spelled this out in the paper somewhere, but I can't immediat= ely find it, so that may be an oversight on my part.

On Sat, Oct 3, 2015 at 8= :25 PM, Sean Middleditch <sean.middleditch@gmail.com> wrote:
Unless I&= #39;m missing something (wouldn't surprise me), there's no way spec= ific in the paper for user code to extract the resulting hash from hash_cod= e or the HashCode concept.

The sample implemen= tation code has a member result_type alias and an `operator result_type()` = but those interfaces are not present in the paper.

Seems like a small but rather critical missing piece. :)

--

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