220 34222 article Path: news.gmane.org!.POSTED!not-for-mail From: mechaxcrash@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: relaxing rules for ternary operator. Allow incompatible types. Date: Wed, 30 Aug 2017 07:13:13 -0700 (PDT) Lines: 132 Approved: news@gmane.org Message-ID: References: <1b5ee8eb-53df-4e98-af2f-829c7bc2e5b2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9659_960297681.1504102393638" X-Trace: blaine.gmane.org 1504102412 4065 195.159.176.226 (30 Aug 2017 14:13:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 Aug 2017 14:13:32 +0000 (UTC) Cc: ma.kalbfuss@web.de To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ55KUTVQDRB6UPTPGQKGQEW6G2IFA@isocpp.org Wed Aug 30 16:13:23 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dn3jx-0008Uz-2J for gclcip-std-proposals@m.gmane.org; Wed, 30 Aug 2017 16:13:09 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id d78sf1387301ioe.18 for ; Wed, 30 Aug 2017 07:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=A3S26cyo/rVzvmrJklzGiXmEH5lQsGKxXRypMBXxXJs=; b=DiwQ4fw2db5phGcbXU3JMOqYQLIOxUXUze/zDK1vo2cKPNlfMz1PspaS8ZTEehaVck d4prVjQwcfAEjHQnaUnrvFuSyMVVQ9zLYWz2ys0ZtwtV1RYEe4GiYBZRUd0z9nUtjB+r 6McxNXK25SUjw8YDMRjlvnS1wH7l1LKFaVKQGzkUXwX3XN8ZwlDybxaFvkzmMY5o+/N0 BCt5szDWme8WcihN3gsYLH1Hb7ymL8d0/KjmhxW76P6uUHjPyRVAqyCigdMzCBKPKK4R tJWe1YkQ4+BlwMi2AlFxh9ItQf4ZDkL2gIBsOUhGsLFSqpOVdFXMgi+7SzCeV4f35ZRK cFvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=A3S26cyo/rVzvmrJklzGiXmEH5lQsGKxXRypMBXxXJs=; b=d4Bvbp9p6+4ZIeOa7DnwLpFlI/U8WFH2qGoNOENGEF2lGWZegYQdjXauHnCs6m5SDS uoXKewG/RHqZOyLA/O4ZXRRA+3DpZDdSuwSnq4VsLFkuDjLcgKmcT34dOZc9wynTpDEH CBNJgAwP/TVRug6iX3GcgrORT9JfmjTbePIDx72lN4Kyy1ucvpVSUGRM5XrX2a6ReQ3s H5tltOLwj9QVNUvxc5iCdSebdBPO9BKtdVgF8Et0Hv0kA0GqyI0sROJme1XMu9T9fujE nGWmKk18u4U78+IPWICLBzECdxjXe/z98pJ7ynHIFlG8v2MATfoKfT9L2gcofRbLRptC Iosg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=A3S26cyo/rVzvmrJklzGiXmEH5lQsGKxXRypMBXxXJs=; b=hNaeyrFYVhtxf4uRpBK3o8SfSwQc4X7quKdUhNc/30R+dgznsnLwS1c1gfj52P4zuU a2VZQNV8lilivp2aa6bsE9+1tPG+K87HOI0at6LHLu05IxW7FnTnvUwILs/XyPca4u6H dKWg2Vidgk/m72Uz8zbPlzaTPFgSxuqOZYMKCesVX8O57OJ5/q4x2BMm83Oq5+2KIAOA tjccao4OBv4TltXIeXQXWGmNN1Zy7EVXIu5BsH8gR96HeMxLc8ZU002DRN1dgJg6Flbc nxZso8oJ3q7xxUDlC5ucasEs7o0wb8VmvX/iqVPbAa4mF+AfWIO36YjOQAuTFFShUodE cuuQ== X-Gm-Message-State: AHPjjUh4+kXXs41evaT661cx1vCtis+UTkxE+IJrE/ktsBo3LydN/ZF9 2FBqm8CDgioGvLc/ X-Google-Smtp-Source: ADKCNb7s6Vep6JMhEvwTg/ihOVsXScIjHBIh8kI698lGD9tAgKRiwvCIrqFUaey3sjPuJeeT7PkUqA== X-Received: by 10.107.169.30 with SMTP id s30mr487539ioe.109.1504102395594; Wed, 30 Aug 2017 07:13:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.36.216 with SMTP id f207ls3215125ita.22.gmail; Wed, 30 Aug 2017 07:13:14 -0700 (PDT) X-Received: by 10.31.171.78 with SMTP id u75mr15849vke.19.1504102394099; Wed, 30 Aug 2017 07:13:14 -0700 (PDT) In-Reply-To: <1b5ee8eb-53df-4e98-af2f-829c7bc2e5b2@isocpp.org> X-Original-Sender: mechaxcrash@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:34222 Archived-At: ------=_Part_9659_960297681.1504102393638 Content-Type: multipart/alternative; boundary="----=_Part_9660_293199867.1504102393638" ------=_Part_9660_293199867.1504102393638 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the necropost, but I feel like this should be discussed further. With C++17 and what's been accepted into 2a so far, we can achieve some=20 very powerful code - but it's also unnecessarily complex. with the removal of trigraphs in C++17, maybe something like ??: could be a= =20 terse solution, or as the ternary operator only applies to expressions it= =20 could be constexpr "where possible" (contextually aware) - I don't think=20 this would change the meaning of pre-existing code in any way. As an example, with C++2a we can achieve something similar to this:=20 (creates constexpr heterogeneous list and returns a copy with a specified= =20 element removed from it) https://godbolt.org/g/p6TWFp while with a constexpr ternary it could be shortened to: https://godbolt.org/g/zNyb6q For the relevant code, you're removing 7 lines of rather ugly code,=20 removing the reliance of inferred value passing (though this could be=20 achieve similarly with .operator()<> - GCC doesn't support this however)=20 and reducing template instantiations. I think this is a big deal, and definitely something people would find a=20 use for moving forwards. On Saturday, 20 May 2017 18:41:57 UTC+1, ma.ka...@web.de wrote: > > Hi Guys, > > I had the following situation: > > I have a Group of StaticSet classes with a compatible interface but=20 > distinct in there concrete type. empty_set is not an intervall! > I tried the following: > > > auto dec_digit =3D make_interval('0', '0' + std::min(base, DECIMAL_BASE) = -=20 > 1); > auto upper_digit =3D (base > DECIMAL_DIGIT) ? make_interval('A', 'A' + (b= ase=20 > - 1 - DECIMAL_BASE)) : empty_set; > auto lower_digit =3D (base > DECIMAL_DIGIT) ? make_interval('a', 'a' + (b= ase=20 > - 1 - DECIMAL_BASE)) : empty_set; > > > Wouldn't it be possible to allow such code, especially in conjunction wit= h=20 > concepts? > > MFG > > Martin Kalbfu=C3=9F > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/aa3f0ad3-d95b-4937-9264-5924a31a84f2%40isocpp.or= g. ------=_Part_9660_293199867.1504102393638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the necropost, but I feel like this should be di= scussed further.

With C++17 and what's been accepted into 2a so = far, we can achieve some very powerful code - but it's also unnecessari= ly complex.

with the removal of trigraphs in C++17, maybe something = like ??: could be a terse solution, or as the ternary operator only applies= to expressions it could be constexpr "where possible" (contextua= lly aware) - I don't think this would change the meaning of pre-existin= g code in any way.

As an example, with C++2a we can achi= eve something similar to this: (creates constexpr heterogeneous list and re= turns a copy with a specified element removed from it)
https://go= dbolt.org/g/p6TWFp
while with a constexpr ternary it could be sho= rtened to:
https://godbolt.org/g/zNyb6q

= For the relevant code, you're removing 7 lines of rather ugly code, rem= oving the reliance of inferred value passing (though this could be achieve = similarly with .operator()<> - GCC doesn't support this however) = and reducing template instantiations.

I think this= is a big deal, and definitely something people would find a use for moving= forwards.

On Saturday, 20 May 2017 18:41:57 UTC+1, ma.ka...@web.de = wrote:
Hi Guy= s,

I had the following situation:

I have a Group of StaticSet= classes with a compatible interface but distinct in there concrete type. e= mpty_set is not an intervall!
I tried the following:


auto dec= _digit =3D make_interval('0', '0' + std::min(base, DECIMAL_= BASE) - 1);
auto upper_digit =3D (base > DECIMAL_DIGIT) ? make_interv= al('A', 'A' + (base - 1 - DECIMAL_BASE)) : empty_set;
au= to lower_digit =3D (base > DECIMAL_DIGIT) ? make_interval('a', &= #39;a' + (base - 1 - DECIMAL_BASE)) : empty_set;


Wouldn'= t it be possible to allow such code, especially in conjunction with concept= s?

MFG

Martin Kalbfu=C3=9F

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/aa3f0ad3-d95b-4937-9264-5924a31a84f2= %40isocpp.org.
------=_Part_9660_293199867.1504102393638-- ------=_Part_9659_960297681.1504102393638-- .