220 10255 <36091227-9aa0-4202-b221-5d4a0ec9b92e@isocpp.org> article Path: news.gmane.org!not-for-mail From: DeadMG Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N3573: Why heterogenous extensions to unordered containers will not work Date: Wed, 16 Apr 2014 10:34:29 -0700 (PDT) Lines: 54 Approved: news@gmane.org Message-ID: <36091227-9aa0-4202-b221-5d4a0ec9b92e@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1385_13208538.1397669669703" X-Trace: ger.gmane.org 1397669681 26963 80.91.229.3 (16 Apr 2014 17:34:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Apr 2014 17:34:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDFMT44JSEMBBJ76XKNAKGQEN5LSXGQ@isocpp.org Wed Apr 16 19:34:35 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WaTjE-0004qB-Rf for gclcip-std-proposals@m.gmane.org; Wed, 16 Apr 2014 19:34:33 +0200 Original-Received: by mail-qc0-f199.google.com with SMTP id e16sf36524422qcx.6 for ; Wed, 16 Apr 2014 10:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=BHbWNexfnCq+Qa6POwLCAUFnAv+VinutZ+lQ5GUAPH0=; b=vHrxUCKf0KrjAYvMCbUoueAClk6zElP/yNMCCmlOm5Pq6LhEwT6maYr17/uZoj95x9 2MUjmGCBtPk9J4rSCPr1zFg5gawGvcK+9uX+W7ZlCipk1/zo6DNdn9VUWNtsyY5/9GKE 2OSAxRUWma62SDRba+iDqsWSoLKkZ5MOUydV1GGEB1Bsr7Bbvyv3c++jR0y8WiPBCuem yPypbsuaa0qqM2cRjMSQIEoVba2PFQMtJtOzaeMeR87TJZpd8A3OEIG/n80Wd23UpEqP ADd+McmAg6oJn9iVEt/U1F7nNtwHCgBHRVM1pSIL48g95zGtxRY61msDbEFHfkdbhYld NWaQ== 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:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=BHbWNexfnCq+Qa6POwLCAUFnAv+VinutZ+lQ5GUAPH0=; b=HTMpRMEAhHl96sL7gYt+U1GGlgBhHFiXLdJdB0Zn8T8eX1/u/Stm+BjfbU0Xw8/dLB OnvMQ9coyvmIpWOPpwPhDkGr0UfdQAsIEyQe8cqUoCCC9sP0AZLDHgqtSXk2guu7feY6 sBJ/tvHd7m28ZUxhMSABqDMl89u4ZP5c9qh9mbc3LpDuQ6rRci/aYrb29O+pr4j+OiNh HWkNtEaL3uBztFOlb5EWACqGEjJL59ifzJ3rn8wKO+VxWFeClHfJrOz5ELvlCk7hRfX8 qhjqMg75DvhQUOAYc2Uz2ZW2IgiicKN5UV2Ql7t3TWyG9JGq5wlhL7JMrv5ECd7KfHEk IavQ== X-Gm-Message-State: ALoCoQlB9t+Uw3TF0etbJMgfystKdknsbEo2nSxlTHTOxKjCijufg40snB0zMMxooiet9AUqCvfn X-Received: by 10.58.178.81 with SMTP id cw17mr4194480vec.37.1397669671949; Wed, 16 Apr 2014 10:34:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.97.134 with SMTP id m6ls718834qge.88.gmail; Wed, 16 Apr 2014 10:34:30 -0700 (PDT) X-Received: by 10.140.95.178 with SMTP id i47mr219879qge.10.1397669670866; Wed, 16 Apr 2014 10:34:30 -0700 (PDT) In-Reply-To: X-Original-Sender: wolfeinstein@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:10255 Archived-At: ------=_Part_1385_13208538.1397669669703 Content-Type: text/plain; charset=UTF-8 No, no it would not. Consider the original motivation in the paper- unique_ptr and T*. Since there's already a hash specialization for unique_ptr, you could not add one for T* later. Obviously for a Standard type this is not a big deal but you cannot go back and enable it for, say, boost::shared_ptr after the fact. This would only work if the author of some given T knows all the possible types U which might be meaningful here, and that's just not a very good system. Better would be to use a separate trait to control which types are and are not eligible. -- --- 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_1385_13208538.1397669669703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, no it would not. Consider the original motivation in t= he paper- unique_ptr<T> and T*. Since there's already a hash speciali= zation for unique_ptr, you could not add one for T* later. Obviously for a = Standard type this is not a big deal but you cannot go back and enable it f= or, say, boost::shared_ptr after the fact. This would only work if the auth= or of some given T knows all the possible types U which might be meaningful= here, and that's just not a very good system.

Better would be to us= e a separate trait to control which types are and are not eligible.

--

---
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_1385_13208538.1397669669703-- .