220 12117 article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: std::order -- what do you think? Date: Wed, 30 Jul 2014 12:15:46 -0400 Lines: 176 Approved: news@gmane.org Message-ID: References: <0ba9643b-7a18-4ab6-a8f7-caec2450c061@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c33d70f6e74904ff6b77b7 X-Trace: ger.gmane.org 1406736958 9133 80.91.229.3 (30 Jul 2014 16:15:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 16:15:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQILHNHETYCRUBG2RICYQ@isocpp.org Wed Jul 30 18:15:51 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f71.google.com ([74.125.82.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XCWXd-0003s4-2p for gclcip-std-proposals@m.gmane.org; Wed, 30 Jul 2014 18:15:49 +0200 Original-Received: by mail-wg0-f71.google.com with SMTP id a1sf967379wgh.10 for ; Wed, 30 Jul 2014 09:15: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:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=yKVQyVOCTV0iPjezt90rfFXS4buAjW0WFJ/71fOn3iM=; b=j4NZkOHs6fwN+ghFGs/D+VnayqpqnTAZgCR3NMHx4wF9X4djpHJcFaqL9VHTgwHjxW qdx/2p76GOiCNszCy0wNgQ1Mw7zMhfTMv4IOnCDJ8KRREUoIZtkkj0RtwcqFYH+k2Ami s3dXLkjuxtxG3xP/RtAjcup4IFKKef1tccn/AAcXhyfVclz345EzB/a3/v2UrQXv3bpk f44khk/lin69ZcXUWlepgP9iJ+IkJpLg4Bv1h+6O07W8gO+/I5IrkPUbAbSARj/PQaQz FLTIpUyB+lYmvZoNMAEUjM7qf9hdn8iYHH4w3HdePgJRn1PitUKQj3MOxAsBCfrp2s8R 7sKA== X-Gm-Message-State: ALoCoQl7m4G3Qz8gYBrBqrl7B9kGqG+CuESNNmRqdCRX5zxHy893LidWwZUel5f3baIfLGDKIuVu X-Received: by 10.180.89.232 with SMTP id br8mr637669wib.1.1406736948203; Wed, 30 Jul 2014 09:15:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.19.131 with SMTP id f3ls133203lae.71.gmail; Wed, 30 Jul 2014 09:15:46 -0700 (PDT) X-Received: by 10.152.37.99 with SMTP id x3mr5800953laj.55.1406736946580; Wed, 30 Jul 2014 09:15:46 -0700 (PDT) Original-Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [2a00:1450:4010:c03::22a]) by mx.google.com with ESMTPS id t6si4536282lat.118.2014.07.30.09.15.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 09:15:46 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::22a as permitted sender) client-ip=2a00:1450:4010:c03::22a; Original-Received: by mail-la0-f42.google.com with SMTP id pv20so1083154lab.1 for ; Wed, 30 Jul 2014 09:15:46 -0700 (PDT) X-Received: by 10.112.198.34 with SMTP id iz2mr5550592lbc.96.1406736946094; Wed, 30 Jul 2014 09:15:46 -0700 (PDT) Original-Received: by 10.113.4.162 with HTTP; Wed, 30 Jul 2014 09:15:46 -0700 (PDT) In-Reply-To: <0ba9643b-7a18-4ab6-a8f7-caec2450c061@isocpp.org> X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::22a as permitted sender) smtp.mail=tvaneerd@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:12117 Archived-At: --001a11c33d70f6e74904ff6b77b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2014 at 9:25 AM, Andrzej Krzemie=C5=84ski wrote: > Hi Everyone, > > TL;DR: A new functor std::order that would be used in ordered containers > by default, and would work for std::complex. > .... > What do you think about such addition? Or is something like this already > considered in LEWG? > > "Considered"? Yes. Formally Proposed? Not that I know of. Alisdair and I promised each other to work together on it in order to prevent either of us from procrastinating on it. Guess what, we are both too good at procrastination. One thing to keep in mind - we can't just do std::order and then say "map now uses std::order by default", as this has backwards compatibility issues= .. ie every map that was map> can't change to map>, because that will break ABI somewhere, and who knows what else. Instead, we need another level of indirection (which solves everything, right?): map<> needs to become template::order> class map ....; and std::lookup_order is template struct lookup_order { typedef std::less less; }; And then you overload lookup_order. Or maybe lookup_order can somehow test whether std::order has been specialized or not: template struct lookup_order { typedef if_c::value, std::order, std::less> less; }; Otherwise, we wait for the "Concept-ified" STL, at which point we will probably break lots of things, so we could break map<> et al then. Regards, > &rzej > > > I am supportive of anything that will "fix" map's use of less, and return less to meaning *exactly* the same as "call < for me". Tony P.S. optional (and expected) should maybe still have <, as one of the stated design goals is "to be as similar to T as possible". If we don't want optional to have <, then let's just overload std::less>. and not implement <, and be done with it. I'd be OK with that. Basically, we need to decide if "like T" is an attainable design goal (and without overloaded operator . it isn't), and whether getting half-way there is a benefit or a hindrance. --=20 ---=20 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 e= mail 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-proposa= ls/. --001a11c33d70f6e74904ff6b77b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 30, 2014 at 9:25 AM, Andrzej Krzemie=C5=84ski <akrzem= i1@gmail.com> wrote:
Hi Every= one,

TL;DR: A new functor std::order that would be used in ordered c= ontainers by default, and would work for std::complex.
...
What do you think about such addition? Or is someth= ing like this already considered in LEWG?


"Considered"? Yes.=C2= =A0 Formally Proposed? Not that I know of.

Alisdair and I= promised each other to work together on it in order to prevent either of u= s from procrastinating on it.=C2=A0 Guess what, we are both too good at pro= crastination.

One thing to keep in mind - we can't just do std::order = and then say "map now uses std::order by default", as this has ba= ckwards compatibility issues.

ie every map<X> that was map<= X, std::less<X>> can't change to map<X, std::order<X>= >, because that will break ABI somewhere, and who knows what else.

Instead, we need another level of indirection (which solves everything,= right?):

map<> needs to become

t= emplate<typename T, typename Ordering =3D std::lookup_order<T>::or= der>
class map ....;

and std::lookup_order is
template <typename T>
struct lookup_order<= br>{
=C2=A0=C2=A0=C2=A0 typedef std::less<T> less;
<= /div>
};

And then you overload lookup_order.
Or maybe l= ookup_order can somehow test whether std::order has been specialized or not= :

template <typename T>
struct lookup_order=
{
=C2=A0=C2=A0=C2=A0 typedef if_c<std_order_specialized_ma= gic<T>::value, std::order<T>, std::less<T>> less;
<= /div>};


Otherwise, we wait for the "Concept-ifie= d" STL, at which point we will probably break lots of things, so we co= uld break map<> et al then.

Regards,
&rzej



I am supportive of anything that will "fix" map's use o= f less, and return less to meaning *exactly* the same as=C2=A0 "call &= lt; for me".
Tony

P.S. optional (and expected) s= hould maybe still have <, as one of the stated design goals is "to = be as similar to T as possible".
I= f we don't want optional to have <, then let's just overload std= ::less<optional<T>>. and not implement <, and be done with i= t.=C2=A0 I'd be OK with that.
Basically, we need to decide if "like= T" is an attainable design goal (and without overloaded operator . it= isn't), and whether getting half-way there is a benefit or a hindrance= ..



--

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