220 40632 <88979389-5cc8-4e28-902c-eb2512411b0e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Can we move consteval out of declarations into an "evaluation specifier" Date: Fri, 19 Oct 2018 07:04:49 -0700 (PDT) Lines: 159 Approved: news@gmane.org Message-ID: <88979389-5cc8-4e28-902c-eb2512411b0e@isocpp.org> References: <29c8c6b5-18f7-48ff-8d43-f0c0ca90c9fe@isocpp.org> <2fd59c48-8023-49f0-a520-33170f9aea04@isocpp.org> <91fb2dcc-8bac-40b3-8dff-6629ecb06b1a@isocpp.org> <6bcc1bdf-7aee-4300-9b7d-eb9e459c0552@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3584_744431244.1539957889798" X-Trace: blaine.gmane.org 1539957772 29999 195.159.176.226 (19 Oct 2018 14:02:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 14:02:52 +0000 (UTC) Cc: mihailnajdenov@gmail.com, pasa@lib.hu To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBAWJU7PAKGQEVWFCZEI@isocpp.org Fri Oct 19 16:02:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f198.google.com ([209.85.219.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDVMP-0007ZL-W1 for gclcip-std-proposals@m.gmane.org; Fri, 19 Oct 2018 16:02:42 +0200 Original-Received: by mail-yb1-f198.google.com with SMTP id w15-v6sf19559696ybm.15 for ; Fri, 19 Oct 2018 07:04:52 -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=6GtzUH+bpniPz5DPYbJiGMCl2tzPZG7QZg6Vh1eIKGg=; b=xPBBpYMHF9BjxNs60sXWJmNVTqHYKU4TFm/1TvjsK3ybNDJqHgZNwkkv5VCAG3P6rn mrUHiVVR2XmlKSwrzgm/hHYj7arqxf5e02tcNH/23EwLRGCHUyzjJyuYsYziXc/Sl2MS Py5MDeRUzhkbxZUJJcTVwbBW2QB5Bnf6uJPWc9XrEMnh6BmbR39cmdeYS/zlvxgeKnIM +59p6Y0wwubajW1yzZ1G3tnszqt997Axe7cjn0pBkYINo/iHvUaL4whrVg6ipmWHz9xs 8quRHfYYD1wmm9pWi5mUBYHCCXmGt6IYqIN13pup2j/xuHMe+JHO6lEJqrKtmKtlMFUL 8RbQ== 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=6GtzUH+bpniPz5DPYbJiGMCl2tzPZG7QZg6Vh1eIKGg=; b=utFPzjFrSkTBOumc2GOg6smNo0JCC0pmbJ+EQM4Z5/sJxtL4e+TpeS/Apdiy/eG3Kf DtCtdTI7spgNbnk7B1G0EGbbjsHTCqIWq7D3e94sHhUGPXszwQSslKiFPIeSjc31Gjef iNpnlNyscBuOWd8nGq6Fgx/XXMfDrRrSQ/H/58mFbgef/x45Q5tNLckv3ogb0hMBWRd3 LehTpH460LyRjKS11ibRxQLI8LVZtq0mDV1OhcRjAj2L6tNJ/og6fo0z4Wvw2Cv1o+ej B6Zd7nvEs/P8jiAtteugEhzZoxwfK/KrR4FC+2lj2E2vLYyrreDpAVWKkTVymauGFJbC 6LSw== 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=6GtzUH+bpniPz5DPYbJiGMCl2tzPZG7QZg6Vh1eIKGg=; b=UmGavL/Mt+o7YeqTHDt3Ga9MTBZswDZE3/4dECdo8iNswbDL/mE8oizaLTjgPsvLQO XNt341YPLEkUkRbv/njf3SWncKwCM8+zdZDA7csfHZ8MgnJFDxqr6lfrrgb4Ut416OzF At2YuPOvA4+uRKJ+sfpRzk6lJdYM3JpH6e+Z8fLrMbpUZ9g8kzXYjOVgCf1xyDHXVat9 MSRmFEOOe13QwCf535E1AwOTjW94dJafzBOUHWtbXObLGgWMpmc87DbLNdluDg+KG5Tk SMDQvjgThjavRtJDKE/ONCEz6fiS5K1KPMLW4qAfr/D/bwDolQwpXw1JYuzfoFbyxI7M dZ/Q== X-Gm-Message-State: ABuFfoiUuUPYqwtKzX0CM8ne5OlGIS9/tJKFpSBGqrHnSMoT73Tczwp8 hHio9Udt24pdYA+WXDKy1jaNgA== X-Google-Smtp-Source: ACcGV63LVzwXkUSB4LEjqS86T7WAWbihzBPA+e5GhM9WcSX9JfWnmr4ILfgeP+YP0PdeKdxYx8P4Vg== X-Received: by 2002:a25:330a:: with SMTP id z10-v6mr20735242ybz.100.1539957892289; Fri, 19 Oct 2018 07:04:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:9951:: with SMTP id q78-v6ls7749752ywg.3.gmail; Fri, 19 Oct 2018 07:04:50 -0700 (PDT) X-Received: by 2002:a0d:dd42:: with SMTP id g63-v6mr388800ywe.2.1539957890367; Fri, 19 Oct 2018 07:04:50 -0700 (PDT) In-Reply-To: <6bcc1bdf-7aee-4300-9b7d-eb9e459c0552@isocpp.org> X-Original-Sender: MihailNajdenov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:40632 Archived-At: ------=_Part_3584_744431244.1539957889798 Content-Type: multipart/alternative; boundary="----=_Part_3585_1491347160.1539957889798" ------=_Part_3585_1491347160.1539957889798 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, October 19, 2018 at 3:10:54 PM UTC+3, pa...@lib.hu wrote: > > > > 2018. okt=C3=B3ber 19., p=C3=A9ntek 9:34:20 UTC+2 id=C5=91pontban mihailn= ....@gmail.com a=20 > k=C3=B6vetkez=C5=91t =C3=ADrta: >> >> I think the status quo should be rethought as we are moving to situation= =20 >> where we need to specify explicitly, something that is effectively a=20 >> default. I am talking about Reflection. All reflection is compile time o= nly. >> >> If we need to mark every function as such this is clearly a design=20 >> deficiency. =20 >> How can a new language solve it? New type of function? A new type of=20 >> enclosing namespace or class? >> >> With "All things constexpr" we are also moving to similar situation - Al= l=20 >> of STL is constexpr and each and every function is decorated. >> This is not good. >> >> Even today something like a QPoint that can be constexpr must decorate= =20 >> every and each function. >> >> We could and should think of a better way. >> >> May be we could decorate a namespace or a class and have a "reverse"=20 >> keyword to mark the exceptions of the rule. >> > > =20 > As I see, a facility to apply some tweak to a large region has a huge=20 > demand. Including my paper P1112R0=20 > if= =20 > you look at the very end. So I think instead of patching up individual=20 > cases like mass consteval It would be better to have a solution supportin= g=20 > multiple clients. Both already existing ones and coming in the future. = =20 > > As I mentioned before, it is mostly alien to the current language=20 > structure, I found one feature that comes close, the extern "C" {} bloc= k.=20 > It is already in the language, the compilers need to deal with it and the= =20 > users are supposedly aware of related problems like moving the code in.ou= t.=20 > > Maybe we could generalize that block for different effects, including to= =20 > alter defaults, apply attributes or consteval.=20 > Problem is, introducing a scope is a problem of its own - for instance it= =20 can't be applied to a bulk of member functions.=20 All options should be evaluated, sadly it seems noone is working on this,= =20 though now is the best time as the the needs is sky high and will only rise= .. --=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/88979389-5cc8-4e28-902c-eb2512411b0e%40isocpp.or= g. ------=_Part_3585_1491347160.1539957889798 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, October 19, 2018 at 3:10:54 PM UTC+3, p= a...@lib.hu wrote:


2018. okt=C3=B3ber 19., p=C3=A9ntek 9:34:20 UTC+2 id=C5=91pont= ban mihailn...@gmail.com a k=C3=B6vetkez=C5=91t =C3=ADrta:
I think the status quo shoul= d be rethought as we are moving to situation where we need to specify expli= citly, something that is effectively a default. I am talking about Reflecti= on. All reflection is compile time only.

If we need to m= ark every function as such this is clearly a design deficiency.=C2=A0=C2=A0=
How can a new language solve it? New type of function? A new typ= e of enclosing namespace or class?

With "All = things constexpr" we are also moving to similar situation - All of STL= is constexpr and each and every function is decorated.
This is n= ot good.

Even today something like a QPoint that c= an be constexpr must decorate every and each function.

=
We could and should think of a better way.

Ma= y be we could decorate a namespace or a class and have a "reverse"= ; keyword to mark the exceptions of the rule.
=
=C2=A0
As I see, a facility to ap= ply some tweak to a large region has a huge demand. Including my paper P1112R0 if = you look at the very end. So I think instead of patching up individual case= s like mass consteval It would be better to have a solution supporting mult= iple clients. Both already existing ones and coming in the future.=C2=A0=C2= =A0

As I mentioned before, it is mostly alien= to the current language structure, I found one feature that comes close, t= he=C2=A0=C2=A0 extern "C" {} block. It is already in the language= , the compilers need to deal with it and the users are supposedly aware of = related problems like moving the code in.out.

Maybe we could generalize that block=C2=A0 for different effects, includin= g to alter defaults, apply attributes or consteval.

Problem is, introducing a scope is a problem of i= ts own - for instance it can't be applied to a bulk of member functions= ..=C2=A0
All options should be evaluated, sadly it seems noone is = working on this, though now is the best time as the the needs is sky high a= nd will only rise.

--
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/88979389-5cc8-4e28-902c-eb2512411b0e= %40isocpp.org.
------=_Part_3585_1491347160.1539957889798-- ------=_Part_3584_744431244.1539957889798-- .