220 12115 <0ba9643b-7a18-4ab6-a8f7-caec2450c061@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: std::order -- what do you think? Date: Wed, 30 Jul 2014 06:25:44 -0700 (PDT) Lines: 111 Approved: news@gmane.org Message-ID: <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="----=_Part_1847_160802583.1406726744327" X-Trace: ger.gmane.org 1406726754 31493 80.91.229.3 (30 Jul 2014 13:25:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 13:25:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBWHE4OPAKGQEA5DXWCA@isocpp.org Wed Jul 30 15:25:47 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XCTt4-000649-Lk for gclcip-std-proposals@m.gmane.org; Wed, 30 Jul 2014 15:25:47 +0200 Original-Received: by mail-pd0-f200.google.com with SMTP id w10sf7053964pde.3 for ; Wed, 30 Jul 2014 06:25:45 -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:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=M6k/p9YovUHl3y2bHq3c4r0OWaoiYY3XvXai3Kf710s=; b=A1tzF6qcck2DuvtrWz2csxsRz0zGycPNt8i6XuYSRsAlWv59+Wjx2SRotq5E/iuWgD wz1PH1sSVYhH84eYxqaVszE/gfIgejqu8sKYBNUUv6FGXnWPoJDOv4aT3098i4Bi2lxw vPob+y4rYFwYxaGJsfFzB5fDB4dFB7q7PoJQi2lxjPr7rgfqMalaoLjJ9HgeHuYMBEsX SzIBIxiyEkzcgwmzFudf2fdVcGuSOoKczJq9RvI1TEdrghY64wPxrjmYBmcB1VcO+ZHP DBEjmzmAOsJl6zYUGKi4kTLxKw5aLZeD3XCU/7X+TjZjy0lBxX17RcAxtA25I1t+u1nM cMXg== 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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=M6k/p9YovUHl3y2bHq3c4r0OWaoiYY3XvXai3Kf710s=; b=m+dF/lNE6RBPVilftnJ+CPWgZ1Vxoq+lwUn6JKCwxXYBJ4Bp30NSexgtSKZ/Lo1qSE KnGxKaS4RP3I36zTQJXSZmPvVrGiVnhEcIJdvWsCp7TwoEJd/OOjf2XIE0NgEwiKpKPa yu84domQA8qceHu64PJhTiTvpgcJsJveMjZqZGIKhQhp+3iwNRMJ5MuQi7iwUYiaJi1O NHiWyytfHfn4nQHi4bw/m2QvdqrZj3YCVpDXRaKyVTIyjmSfrJ2DiEeDEHv4tKUNWZeA OavAWA3iBoJJTw0xesLXgNwkv7ujaIxeYqx+RXUby2uKRtYdT18lbcAI+mxYviIMfOVC fE8Q== X-Gm-Message-State: ALoCoQmRI0t06852YA6o2i+YEhAPR3iKitjI1jsZT22vyABmnHaYvZY3W4q4OwP4LqY0N+63f9rm X-Received: by 10.70.103.237 with SMTP id fz13mr1736864pdb.4.1406726745461; Wed, 30 Jul 2014 06:25:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.23.19 with SMTP id 19ls498009qgo.59.gmail; Wed, 30 Jul 2014 06:25:44 -0700 (PDT) X-Received: by 10.140.21.175 with SMTP id 44mr5724qgl.14.1406726744725; Wed, 30 Jul 2014 06:25:44 -0700 (PDT) X-Original-Sender: akrzemi1@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:12115 Archived-At: ------=_Part_1847_160802583.1406726744327 Content-Type: text/plain; charset=UTF-8 Hi Everyone, TL;DR: A new functor std::order that would be used in ordered containers by default, and would work for std::complex. There are two reasons for adding a default order to a user-defined type: 1. To represent the intuitive mathematical notion of two real numbers being greater or smaller. This can be used to check if a value is lower than some defined threshold. 2. To add a criterion for sorting in ordered containers and algorithms that rely on some order. Types like std::string can be ordered by a lexicographical order, but it makes no sense for them to check if they have exceeded a "string threshold". You can define operator< for a string, but it is somewhat artificial and confusing. It is even more confusing for std::optional: you can define operator< for it with some meaning (e.g., that uninitialized optional is some special value less than any T), but it has no intuitive meaning that would help with interpreting when an optional exceeds a threshold. While std::string is a lost case as it already defines operator<, it is possible to avoid adding it to optional, while still making it usable in ordered containers. More, we could make std::complex useful in ordered containers. The solution was proposed here a couple of times. Define function template order<> that would either fall back to std::less or use user-provided specializations. So for types like std::complex and std::optional we would only specialize std::order, but no std::less and give no operator<. For types like std::integer, we would only define operator< (and std::order will pick it implicitly). For types std::string and std::tuple operator< -- according to the reasoning in this proposal -- should have never been defined, but we keep it for compatibility reasons. They could be deprecated and std::order specializations still provided. What do you think about such addition? Or is something like this already considered in LEWG? Regards, &rzej -- --- 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_1847_160802583.1406726744327 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everyone,

TL;DR: A new functor std::order that w= ould be used in ordered containers by default, and would work for std::comp= lex.

There are two reasons for adding a default order to a user-defi= ned type:
  1. To represent the intuitive mathematical notion of two = real numbers being greater or smaller. This can be used to check if a value= is lower than some defined threshold.
  2. To add a criterion for sorti= ng in ordered containers and algorithms that rely on some order.
<= p>Types like std::string can be ordered by a lexicographical order, but it = makes no sense for them to check if they have exceeded a "string threshold"= .. You can define operator< for a string, but it is somewhat artificial a= nd confusing. It is even more confusing for std::optional<T>: you can= define operator< for it with some meaning (e.g., that uninitialized opt= ional is some special value less than any T), but it has no intuitive meani= ng that would help with interpreting when an optional<T> exceeds a th= reshold.

While std::string is a lost case as it already defines opera= tor<, it is possible to avoid adding it to optional<T>, while stil= l making it usable in ordered containers. More, we could make std::complex = useful in ordered containers.

The solution was proposed here a couple= of times. Define function template order<> that would either fall ba= ck to std::less or use user-provided specializations.

So for types li= ke std::complex and std::optional we would only specialize std::order, but = no std::less and give no operator<.

For types like std::integer, w= e would only define operator< (and std::order will pick it implicitly).<= /p>

For types std::string and std::tuple operator< -- according to the= reasoning in this proposal -- should have never been defined, but we keep = it for compatibility reasons. They could be deprecated and std::order speci= alizations still provided.

What do you think about such addition? Or = is something like this already considered in LEWG?

Regards,
&r= zej

--

---
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_1847_160802583.1406726744327-- .