220 33956 <12275369-dca3-40aa-b37c-93d60ffc3db8@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: shmitti.guardia@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal for two new traits: `std::greedy_conjunction` and `std::greedy_disjunction ` Date: Thu, 17 Aug 2017 03:02:56 -0700 (PDT) Lines: 813 Approved: news@gmane.org Message-ID: <12275369-dca3-40aa-b37c-93d60ffc3db8@isocpp.org> References: <4b2924fd-0a54-45eb-a2c3-55ddbb5edd73@isocpp.org> <81a6a1fa-a331-483e-8f4d-4184c661b106@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_868_1660773175.1502964176680" X-Trace: blaine.gmane.org 1502964183 15222 195.159.176.226 (17 Aug 2017 10:03:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Aug 2017 10:03:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCSIDV7PUYJBBUOT2XGAKGQE42LAC5Y@isocpp.org Thu Aug 17 12:02:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1diHdd-0003Tn-0d for gclcip-std-proposals@m.gmane.org; Thu, 17 Aug 2017 12:02:53 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id o72sf54158837ita.3 for ; Thu, 17 Aug 2017 03:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=UDSVPafmqVPnh7xoupKL2jt0dZVEqaRFlN9+6NwjjjQ=; b=qumPdO+mwLGdNcWDiZYlLmh8YSv5B+cYoQV1ECkV8bbH6WgZne02fawA26DzfQN8HE QXLUjLL5jhKWTziorQKmmAYk4WbmCOHd80gOWJ6x1TzQC/RwwUuFl5QL4rQdvHU3ieoK Sg2lZDS4oBAr8svPnsBSz7ZLAWT2L2RcnINC6AVSScJhcP6PyxUfvxbmitC7VW/1C6h8 jXx6YB4XTDa1OOCG3oCL/K3QNcbg7ZqvL8GYe19oPeUXjBfK5L9/SOjCaIgzYA/w4mH4 2+ALYInaPm2aggiNM3Au4t+pdflQw8basFRUqqogRpGeeKbqpE9fhR6vjROA8n0pFdpk k38A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=UDSVPafmqVPnh7xoupKL2jt0dZVEqaRFlN9+6NwjjjQ=; b=c+mcFCN572JuLIVsV24xuOMGd3xo9FjvBQj8R1HTAizuSeDwzUaKi4Yon95o/HYFYH dbQ4YdzGJ5nHflJtgbHRRegQwq9y0MHTmzJZth33S/gT7DUbdi1bbig/JFBnS2ALYCN9 4VlZ+n2uu5e9+UY9eocO7cr+0ytol+PmoiWQSHGHsK3HLpd+zkreHfpZfOzag/+L9pUr FbmeiiWs0pMbq5AifdSVTzu1c1cG/DYu0i0DrxxVKT/GHOxp6IZp3shqhJi9tt1vQvPD CMGnqlhrx8rVchn0oVv0/4jJ7J9vwX6CAfJaCjFPm/i8QK0VMUattUS+Rs3COF0yAM6g 3TOA== 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: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=UDSVPafmqVPnh7xoupKL2jt0dZVEqaRFlN9+6NwjjjQ=; b=bAucg7SUMZPXixlZV1Z51QZQN6TmRdkxpK5CAAtWBIMmsxmDcHa6ah7dYjaizeK0vJ 0wuUOyWTujoH6gcg4uO3Qj3lVGvH6yzUEEfk70miZ7CDqUA6esRgflIX+L8x6eA8K7nN TG8Nyb2qAmXiWAdyk/Qk3ePSUaAxb3ht5X227Pvj3/c50JCGbUjGxkb5afFtRxe1h5ZH DypQYFkHwmAQc/wjlfKnLunbUhKcxQvGyL5W6ohLeHR3oJwrkZvjMcUvbM15jE4NQX9k eHNyrQLFwmmfsu0sYaWi2svmBl5lvn+aBlBA1NTQDq9c1HWR8SmStiTIVgeP6KGjlbq+ x3WQ== X-Gm-Message-State: AHYfb5gXhFiaBdc9EXAKdttgK8OuMySaIqB6YmIJAqJN6qPIxRXY4cq2 HoZiqymUovI64bQS X-Received: by 10.107.35.200 with SMTP id j191mr2977233ioj.51.1502964178646; Thu, 17 Aug 2017 03:02:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.25.69 with SMTP id b66ls2767965itb.19.canary-gmail; Thu, 17 Aug 2017 03:02:57 -0700 (PDT) X-Received: by 10.31.69.82 with SMTP id s79mr46796vka.2.1502964177220; Thu, 17 Aug 2017 03:02:57 -0700 (PDT) In-Reply-To: X-Original-Sender: shmitti.guardia@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:33956 Archived-At: ------=_Part_868_1660773175.1502964176680 Content-Type: multipart/alternative; boundary="----=_Part_869_151071870.1502964176681" ------=_Part_869_151071870.1502964176681 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Got it. Thank you! W dniu czwartek, 17 sierpnia 2017 10:26:13 UTC+2 u=C5=BCytkownik Micha=C5= =82 Dominiak=20 napisa=C5=82: > > What I meant is that you don't really need a specific trait. > > You can't obtain the result of std::{con,dis}junction directly, without= =20 > using a layer of abstraction for the laziness. > > You can, however, obtain the result of the greedy operation directly - by= =20 > just &&ing or ||ing the values of the traits you'd pass to this trait.=20 > Evaluation in templates is already eager that way, and it's no problem to= =20 > && or || them together even in generic contexts, especially since we have= =20 > fold expressions now. > > The reason for the traits that we have is laziness. If you don't need=20 > laziness, you don't need the trait. > > On Thu, Aug 17, 2017, 10:17 AM > wrote= : > >> Hello again, >> I am wondering if lack of response in this thread means that my idea has= =20 >> been already rejected? If yes then could anyone explain why? >> >> I might be wrong but this is why I'm not convicted by the current=20 >> arguments: >> >> >You can already write your "greedy" things by just... deriving from=20 >> bool_constant directly (exactly like in your last snippet). >> I assume that your point is that it's easy to implement by the user on= =20 >> his own. I'm not convicted because there is a lot of stuff in the standa= rd=20 >> library that are easy to implement, e.g. std::negation >> >> >Your thing doesn't seem to be very useful. >> Not sure if I follow. If they are not useful =3D> std::conjunction and= =20 >> disjunction are not as well (: >> As you can see they compute almost same result as std::conjunction and= =20 >> disjunction, plus they give a choice to the user about the compilation t= ime. >> >> The only thing that concerns me here is if it's in the standard library= =20 >> scope to care about the compilation time. >> >> Thanks in advance, >> Mateusz Janek >> >> W dniu =C5=9Broda, 9 sierpnia 2017 23:22:53 UTC+2 u=C5=BCytkownik=20 >> mateusz...@gmail.com napisa=C5=82: >>> >>> These traits are as useful as current conjunction and disjunction are -= =20 >>> they compute the same result, but additionally give user a choice about= =20 >>> compilation time and IMO that's a useful addition. >>> >>> W dniu =C5=9Broda, 9 sierpnia 2017 14:37:05 UTC+2 u=C5=BCytkownik Micha= =C5=82 Dominiak=20 >>> napisa=C5=82: >>>> >>>> You can already write your "greedy" things by just... deriving from=20 >>>> bool_constant directly (exactly like in your last snippet). You couldn= 't do=20 >>>> what the two traits are doing directly, and that's I believe is the on= ly=20 >>>> justification of their existence. Your thing doesn't seem to be very u= seful. >>>> >>>> On Wed, Aug 9, 2017 at 2:31 PM wrote: >>>> >>>>> *Introduction* >>>>> >>>>> C++17 introduced besides the others two new structures in=20 >>>>> `` header: `std::conjuction` and `std::disjunction`. The= y are=20 >>>>> very useful in metaprogramming, but standard has in some way forced t= heir=20 >>>>> implementation.=20 >>>>> In p0013r1=20 >>>>> we=20 >>>>> can read: >>>>> The BaseCharacteristic of a specialization conjunction i= s=20 >>>>> the first type Bi in the list true_type, B1, ..., BN for which Bi::va= lue=20 >>>>> =3D=3D false, or if every Bi::value !=3D false the BaseCharacteristic= is BN.=20 >>>>> [*Note:* This means a specialization of conjunction does not=20 >>>>> necessarily have a BaseCharacteristic of either true_type or=20 >>>>> false_type. =E2=80=94 *end note*] >>>>> >>>>> Similar in the disjunction:=20 >>>>> The BaseCharacteristic of a specialization disjunction i= s=20 >>>>> the first type Bi in the list false_type, B1, ..., BN for which Bi::v= alue=20 >>>>> !=3D false, or if every Bi::value =3D=3D false the BaseCharacteristic= is BN.=20 >>>>> [*Note:* This means a specialization of disjunction does not=20 >>>>> necessarily have a BaseCharacteristic of either true_type or=20 >>>>> false_type. =E2=80=94 *end note*] >>>>> >>>>> I'd like to propose a two new structures in ``:=20 >>>>> `std::greedy_conjunction` and `std::greedy_disjunction`. Their result= s=20 >>>>> would very similar to the ones from `std::conjunciton` and=20 >>>>> `std::disjunction`, but their specification would give more flexibili= ty to=20 >>>>> the standard library creators. >>>>> >>>>> >>>>> *Motivation and Scope* >>>>> >>>>> With `std::conjuction` and `std::disjunction` restrictions in the=20 >>>>> standard, library creators are forced to make them in such (or simila= r) way: >>>>> template struct conjunction : std::true_type { }; >>>>> template struct conjunction : B1 { }; >>>>> template >>>>> struct conjunction=20 >>>>> : std::conditional_t, B1> {}; >>>>> =20 >>>>> template struct disjunction : std::false_type { }; >>>>> template struct disjunction : B1 { }; >>>>> template >>>>> struct disjunction=20 >>>>> : std::conditional_t> {= =20 >>>>> }; >>>>> >>>>> >>>>> =20 >>>>> There are strong grounds to keep these implementations, e.g.=20 >>>>> short-circuiting, getting information on what type, recursion stopped= etc.=20 >>>>> Although, because of these restrictions compilation time suffers in s= ome=20 >>>>> cases. >>>>> >>>>> *Why new, very similar traits?* >>>>> *Abstract* >>>>> During my pull request to folly ( >>>>> https://github.com/facebook/folly/pull/643) Jay Feldblum posted there= =20 >>>>> a small benchmark script:=20 >>>>> https://gist.github.com/yfeldblum/ffae5374aaaa11b03f08919d25b1555b (b= ig=20 >>>>> credits for poking my brain with the idea). I was surprised that, let= 's=20 >>>>> say, the naive implementation compiles faster that the standard one.= =20 >>>>> >>>>> I decided to benchmark this idea deeper: >>>>> -problem was to find in a types sequence if there is a type which=20 >>>>> T::value is equal to 0 >>>>> -for every benchmark sequence has 1024 types inside >>>>> -tested sequences with two kinds of types: light and heavy to=20 >>>>> instantiate >>>>> -tested best and worse cases >>>>> -tested two new implementations: fold expression and bool-pack >>>>> -core benchmark was to measure the compilation time with given=20 >>>>> compiler (clang++-4.0/g++-6), case (best/worse), type (light/heavy),= =20 >>>>> implementation (proposed/standard). Every compilation case was ran 50= 0=20 >>>>> times and average result was calculated. >>>>> >>>>> Whole benchmarks code you can find in the gh repo:=20 >>>>> https://github.com/stryku/boolpack_vs_recursion >>>>> >>>>> And here are the results (sorry for not posting it here, but table wa= s=20 >>>>> too big and it was formatted in unreadable way): >>>>> >>>>> https://raw.githubusercontent.com/stryku/boolpack_vs_recursion/master= /output >>>>> >>>>> As you can see, standard implementation is way better when we deal=20 >>>>> with the best case. It can compile 80x(!) faster than the proposed on= es.=20 >>>>> Problem starts when the worse cases occurs.=20 >>>>> Standard library creators would be able to implement=20 >>>>> `greedy_conjunction` and `greedy_disjunction` in a way that they comp= iles=20 >>>>> up to around 6x faster than the standard one. Users would be able cho= ose=20 >>>>> implementation which will suit best, based on what cases they are mos= tly=20 >>>>> expecting. >>>>> >>>>> *Specification* >>>>> Since it's a pre-proposal I don't want to post fully described=20 >>>>> specification. I'm thinking about it in this way: >>>>> >>>>> `std::greedy_conjunction` would be an alias or would derive from a=20 >>>>> type, which has a constexpr member `value` which can be converted to = bool=20 >>>>> and is equal to: >>>>> -false if any bool(Tn::value0 =3D=3D false >>>>> -true otherwise >>>>> >>>>> `std::greedy_disjunction` would be an alias or would derive from a=20 >>>>> type, which has a constexpr member `value` which can be converted to = bool=20 >>>>> and is equal to: >>>>> -false if all bool(Tn::value) =3D=3D false >>>>> -true otherwise >>>>> >>>>> *Example implementations* >>>>> bool-pack (this one seems to compile faster than fold expression): >>>>> template >>>>> struct __bools {}; >>>>> >>>>> template =20 >>>>> struct greedy_disjunction: std::negation>>>> ::value)...>, __bools<(Tn::value && false)...>>> {}; >>>>> >>>>> template =20 >>>>> struct greedy_conjunction: std::is_same<__bools,= =20 >>>>> __bools<(Tn::value || true)...>> {}; >>>>> >>>>> >>>>> fold expression: >>>>> template =20 >>>>> struct greedy_disjunction : std::bool_constant<(false || ... || bool( >>>>> Tn::value))> {}; >>>>> >>>>> template =20 >>>>> struct greedy_conjunction : std::bool_constant<(true && ... && bool(T= n >>>>> ::value))> {}; >>>>> >>>>> >>>>> *Wordings:* >>>>> *There is couple of questions* >>>>> I asked them to myself a lot, during this pre-proposal. >>>>> -Is it in the C++ standard scope to care about how things will be=20 >>>>> implemented in standard library, even if the implementations will be = not=20 >>>>> efficient on compile-time level? >>>>> -Should the standard be changed because of standard library=20 >>>>> compilation time? >>>>> >>>>> And here's my conclusion (and reason why I'm writing this post). >>>>> C++ standard purpose is not to specify a theoretical language. It's= =20 >>>>> created to be used by a lot of people in the real world. Giving a cho= ice to=20 >>>>> user between implementations which differs in a compile-time efficien= cy is=20 >>>>> same thing as to give a choice between containers e.g. `std::vector` = and=20 >>>>> `std::list`. In some cases one implementation is better, in others th= e=20 >>>>> other one. >>>>> >>>>> *And of course the name* >>>>> I thought about `strict_*` (like it's in Facebook/folly lib) instead= =20 >>>>> of `greedy_*`, but I'm sure that if this proposal is a thing communit= y will=20 >>>>> propose better names. >>>>> >>>>> >>>>> What do you think? >>>>> >>>>> Mateusz (stryku) Janek >>>>> >>>>> --=20 >>>>> You received this message because you are subscribed to the Google=20 >>>>> Groups "ISO C++ Standard - Future Proposals" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>>>> an email to std-proposal...@isocpp.org. >>>>> To post to this group, send email to std-pr...@isocpp.org. >>>>> To view this discussion on the web visit=20 >>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a79ce0b4= -ca2d-4c37-b49e-cb707689a0e2%40isocpp.org=20 >>>>> >>>>> . >>>>> >>>> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> To view this discussion on the web visit=20 >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a6a1fa-a3= 31-483e-8f4d-4184c661b106%40isocpp.org=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/12275369-dca3-40aa-b37c-93d60ffc3db8%40isocpp.or= g. ------=_Part_869_151071870.1502964176681 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it. Thank you!

W dniu czwartek, 17 sierpnia 201= 7 10:26:13 UTC+2 u=C5=BCytkownik Micha=C5=82 Dominiak napisa=C5=82:

What I meant is that yo= u don't really need a specific trait.

You can't obtain the result of std::{con,dis}junction di= rectly, without using a layer of abstraction for the laziness.

You can, however, obtain the result of the greedy operation = directly - by just &&ing or ||ing the values of the traits you'= d pass to this trait. Evaluation in templates is already eager that way, an= d it's no problem to && or || them together even in generic con= texts, especially since we have fold expressions now.

The reason for the traits that we have is laziness. If you d= on't need laziness, you don't need the trait.


On Thu, Aug 17, 2017, 10:17= AM <mateusz...@gmail.com> wrote:
Hello again,
I am wondering if lack of= response in this thread means that my idea has been already rejected? If y= es then could anyone explain why?

I might be wrong= but this is why I'm not convicted by the current arguments:

>You can already write your "= greedy" things by just... deriving from bool_constant directly (exactl= y like in your last snippet).
I assume tha= t your point is that it's easy to implement by the user on his own. I&#= 39;m not convicted because there is a lot of stuff in the standard library = that are easy to implement, e.g. std::negation
=

>Your thing doesn't seem to be very useful.
Not sure if I follow. If they are not useful = =3D> std::conjunction and disjunction are not as well (:
As yo= u can see they compute almost same result as std::conjunction and disjuncti= on, plus they give a choice to the user about the compilation time.

The only thing that concerns me here is if it's in th= e standard library scope to care about the compilation time.

=
Thanks in advance,
Mateusz Janek

W dniu =C5=9Broda, 9 sierpnia 2017 23:22:53 UTC+2 u=C5=BCytkow= nik mateusz...@gmail.com napisa=C5=82:
These traits are as useful as current conjunctio= n and disjunction are - they compute the same result, but additionally give= user a choice about compilation time and IMO that's a useful addition.=

W dniu =C5=9Broda, 9 sierpnia 2017 14:37:05 UTC+2 u=C5=BCytkownik M= icha=C5=82 Dominiak napisa=C5=82:
You can already write your "greedy" things by just= .... deriving from bool_constant directly (exactly like in your last snippet= ). You couldn't do what the two traits are doing directly, and that'= ;s I believe is the only justification of their existence. Your thing doesn= 't seem to be very useful.

On Wed, Aug 9, 2017 at 2:31 PM <mateusz...@= gmail.com> wrote:
Introduction

C++17 introduced besides the others two new structures in `<type= _traits>` header: `std::conjuction` and `std::disjunction`. They are ver= y useful in metaprogramming, but standard has in some way forced their impl= ementation.=C2=A0
In p0013r1=C2=A0we can read:
The BaseCharacteristic of a specialization=C2=A0conjunction<B= 1, ..., BN>=C2=A0is the first= type=C2=A0Bi<= /code>=C2=A0in the list=C2=A0true_type, B1, ..., BN=C2=A0for which=C2=A0Bi::value =3D=3D false, or if every=C2=A0Bi::value !=3D false=C2=A0the BaseCharacteristic is=C2=A0= BN. [Note:<= /em>=C2=A0This means a specialization o= f=C2=A0conjunc= tion=C2=A0does not necessarily h= ave a BaseCharacteristic of either=C2=A0true_type=C2=A0or=C2=A0false_type. =E2=80=94=C2= =A0end note]
The BaseCharacteristic of a specialization=C2= =A0disjunction= <B1, ..., BN>=C2=A0is the = first type=C2=A0Bi=C2=A0in the list=C2=A0false_type, B1, ...= , BN=C2=A0for which=C2=A0= Bi::value !=3D false<= /code>, or if every=C2=A0Bi::value =3D=3D false=C2=A0the BaseCharacteristic is=C2=A0<= /span>BN. [N= ote:=C2=A0This means a specializat= ion of=C2=A0di= sjunction=C2=A0does not necessar= ily have a BaseCharacteristic of either=C2=A0true_type=C2=A0or=C2=A0false_type. =E2=80= =94=C2=A0end note]

I'd like= to propose a two new structures in `<type_traits>`: `std::greedy_con= junction` and `std::greedy_disjunction`. Their results would very similar t= o the ones from `std::conjunciton` and `std::disjunction`, but their specif= ication would give more flexibility to the standard library creators.
=


Motivation and Scope=

With `std::conjuction` and `std::disju= nction` restrictions in the standard, library creators are forced to make t= hem in such (or similar) way:
template<= span style=3D"color:#660"><class...> struct conju= nction : std::= true_type { };=
template<class B1> struct conjunction<B1> : B1 { };
template<class B1, class... Bn>
struct conjunction<B1, Bn...>
=C2=A0 =C2=A0 = : std::conditional_t<= /span><bool= (B1::valu= e), con= junction<Bn...>, B1> {};
=C2=A0 =C2=A0
template<class...> struct dis= junction : std::false_type { };
template<class B1> struct disjunction<B1> : B1 { };
template<class B1, class... Bn>
struct disjunction<B1, Bn...>
=C2=A0 =C2=A0 : std::conditiona= l_t<= bool(B1= ::value),= B1, di= sjunction<Bn...>> =C2=A0{ };


=C2=A0 =C2=A0=C2=A0
There are strong grounds to keep these implementations, e.g. short-c= ircuiting, getting information on what type, recursion stopped etc. Althoug= h, because of these restrictions compilation time suffers in some cases.

Why new,=C2=A0very similar traits?
Abstract
During my pull req= uest to folly (http= s://github.com/facebook/folly/pull/643) Jay Feldblum posted there = a small benchmark script: https:= //gist.github.com/yfeldblum/ffae5374aaaa11b03f08919d25b1555b= =C2=A0(big credits for poking my brain with the idea). I was surprised = that, let's say, the naive implementation compiles faster that the stan= dard one.=C2=A0

I decided to benchmark this idea d= eeper:
-problem was to find in a types sequence if there is a typ= e which T::value is equal to 0
-for every benchmark sequence has = 1024 types inside
-tested sequences with two kinds of types: ligh= t and heavy to instantiate
-tested best and worse cases
-tested two new implementations: fold expression and bool-pack
-= core benchmark was to measure the compilation time with given compiler (cla= ng++-4.0/g++-6), case (best/worse), type (light/heavy), implementation (pro= posed/standard). Every compilation case was ran 500 times and average resul= t was calculated.

Whole benchmarks code you can fi= nd in the gh repo:=C2=A0https://github.com/stryku/boolpack_vs_recursion

And here are the results (sorry for not posting it here, b= ut table was too big and it was formatted in unreadable way):

As you can see, standard implem= entation is way better when we deal with the best case. It can compile 80x(= !) faster than the proposed ones. Problem starts when the worse cases occur= s.=C2=A0
Standard library creators would be able to implement `gr= eedy_conjunction` and `greedy_disjunction` in a way that they compiles up t= o around 6x faster than the standard one. Users would be able choose implem= entation which will suit best, based on what cases they are mostly expectin= g.

Specification
Since it's a pre-proposal I don't want to post fully descri= bed specification. I'm thinking about it in this way:

`std::greedy_conjunction` would be an alias or would derive from a = type, which has a constexpr member `value` which can be converted to bool a= nd is equal to:
-false if any bool(Tn::value0 =3D=3D false
<= div>-true otherwise

`std::greedy_disjunction`= would be an alias or would derive from a type, which has a constexpr membe= r `value` which can be converted to bool and is equal to:
-false = if all bool(Tn::value) =3D=3D false
-true otherwise

Example implementations
bool-pack (this one seems to compile faster than fold expression):<= /div>
template <bool... Bn>
struct __bools {= };

template <typename... Tn>
struct greedy_disjunction: std::negation<= std::is_same<__bools= <bool(Tn::<= /span>value)..= ..>, __bools<(Tn::value && false)...>>><= span style=3D"color:#000"> {};

template <typename...= Tn>
struct gr= eedy_conjunction: std::is_same<__bools<bool(Tn::value)...>, __bools<(Tn::value || true= )...>> <= /span>{};
<= /span>


fold expression:
template <typename= ... Tn>
struct= greedy_disjunction : std::bool_constant<(false || ... || bool(Tn:= :value)= )> {= };

template <typename... Tn>
struct greedy_conjunction : std::bool_constant<(= true && ... <= /span>&& bool= (Tn::value))&g= t; {};<= /span>

Wordings:
There is = couple of questions
I asked them to myself a lot, during this= pre-proposal.
-Is it in the C++ standard scope to care about how= things will be implemented in standard library, even if the implementation= s will be not efficient on compile-time level?
-Should the standa= rd be changed because of standard library compilation time?

<= /div>
And here's my conclusion (and reason why I'm writing this= post).
C++ standard purpose is not to specify a theoretical lang= uage. It's created to be used by a lot of people in the real world. Giv= ing a choice to user between implementations which differs in a compile-tim= e efficiency is same thing as to give a choice between containers e.g. `std= ::vector` and `std::list`. In some cases one implementation is better, in o= thers the other one.

And of course the name=
I thought about `strict_*` (like it's in Facebook/folly lib)= instead of `greedy_*`, but I'm sure that if this proposal is a thing c= ommunity will propose better names.


What do you think?

Mateusz (stryku) Janek

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.o= rg.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/a79ce0b4-ca2d-4c37-b49e-= cb707689a0e2%40isocpp.org.

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/81a6a1fa-a331-483e-8f4d-= 4184c661b106%40isocpp.org.

--
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/12275369-dca3-40aa-b37c-93d60ffc3db8= %40isocpp.org.
------=_Part_869_151071870.1502964176681-- ------=_Part_868_1660773175.1502964176680-- .