220 33805 <7fe1d0c9-79b0-4e18-919a-be56fd102892@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: properties? Date: Thu, 10 Aug 2017 12:12:12 -0700 (PDT) Lines: 192 Approved: news@gmane.org Message-ID: <7fe1d0c9-79b0-4e18-919a-be56fd102892@isocpp.org> References: <17b1a3ed-1590-21ce-328d-053b86d6fc0b@gmail.com> <2fe78db2-1a96-4c22-9439-1c12dea4868e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1236_686147625.1502392333028" X-Trace: blaine.gmane.org 1502392338 23148 195.159.176.226 (10 Aug 2017 19:12:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Aug 2017 19:12:18 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDXAWLGAKGQEH446XKA@isocpp.org Thu Aug 10 21:12:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfssL-0005S0-IZ for gclcip-std-proposals@m.gmane.org; Thu, 10 Aug 2017 21:12:09 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id k20sf24434470ywe.7 for ; Thu, 10 Aug 2017 12:12:15 -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=HuEtF+suI08a2cuhywz6N+MQEeCRL4TXMONjC3olLcQ=; b=DR+BkCXdtZGDXHhz4rpHblKL0wohx1Fx6occ0vK/lK3SMpAjt+MB1WYgFiP/E07C4J +RcFsYT9hCbs3xlDokz7eELX2HWc2aQEiMs5XhF/WzmK3diWHO/8MeKynXemYFWfuVtb RD5Yf5U3KQ3v2Ot0i3teEAYq3OE0hVH87YuwxHCwSKIX1P2X2QG/A6Kbqq6Yr835Qk7A RBu2w84VYNsn2is8J4NxauydFHfqYFPr5IawtZ/a1BD4u+QDZU0ryfOMtznq4JbApHNt Rn4keRx0Yk1s/87SMpOCXtxyIUhJCUcAfy9uejvJKxdkLS1jYHu7+EWET9oa7Gv1wH57 x7cQ== 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=HuEtF+suI08a2cuhywz6N+MQEeCRL4TXMONjC3olLcQ=; b=Fa5wYL2CvS8usnMvrRAEmHkH93lFYCWrOw9SDnT5S/GF1EPKO9jnHaIkXESE5Bqq9R NAslfiqK6NHqIHiYmFl5Ue/M/55EI+c7sqBrR+yeNO3UbOLVsyLwRBEm9PMebWhxk18F eNu9fID53bONfKt4z9Kxo3xKGQaAJPWWASTr6bZw/ZoosYD4BwMZFGWhdXYVZeZuLih4 e5BRcGlY/FOjaNLCSmSAJcDrAN1KIr4PBUk8GZzlfs01yFvbFXGr2axjTTN2dMTpRm0a e/a+Hh+wJ7FXSw03KR0TOEY4sLGkr2aOM4mGp4FpZJR2bmsuONJmTElx3ytJZiFvxG/N j+qQ== 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=HuEtF+suI08a2cuhywz6N+MQEeCRL4TXMONjC3olLcQ=; b=t6eBlUr76j7lDknz6DR/yo0zGYD7mTMJofkExXetwbsM5J3Oj6GekZ9M6bXcmOUyAx ib4A84vTr9Wpozn9LagLiFew1R7OqzImghvnrxnW2zwfJthMSeg8z/bDpJL3boyd44xV uxZCu+Uh/2w9HGI2lzzFdc3Kh1qwfyhDRS6Mf/k1C516zdnJ+Cl+g+Nh2miKSWKTjvBM uDpuMnBs6CnNIMb7vAoSOTOA9wdnrsZLH6cX9Xw2188kshFmY3zKI1Ym5F4atJFqzz/c Xb8PrZNiZgCzi2eJtY2FtKRrlYC0Zoh0gVlS5lg9rHel/jJfc8c3aS5ZAbrSdl2W3O5r blgg== X-Gm-Message-State: AHYfb5j+j3cBqCFT8LoLk+GZVBvUPVbAgTduF+o/W2DKC6nm9bz88sN9 GA3lckAGVYoxn/xh X-Received: by 10.129.145.202 with SMTP id i193mr8079364ywg.184.1502392335210; Thu, 10 Aug 2017 12:12:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.141.4 with SMTP id p4ls12608474iod.30.gmail; Thu, 10 Aug 2017 12:12:13 -0700 (PDT) X-Received: by 10.31.160.13 with SMTP id j13mr78412vke.25.1502392333689; Thu, 10 Aug 2017 12:12:13 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:33805 Archived-At: ------=_Part_1236_686147625.1502392333028 Content-Type: multipart/alternative; boundary="----=_Part_1237_1511278969.1502392333029" ------=_Part_1237_1511278969.1502392333029 Content-Type: text/plain; charset="UTF-8" On Thursday, August 10, 2017 at 1:38:25 PM UTC-4, Ville Voutilainen wrote: > > On 10 August 2017 at 20:14, Nicol Bolas > > wrote: > > I guess it's more a matter of the fact that it's a very far future > thing. > > C++20 is highly unlikely to see purely introspective reflection. So the > > chance of code generation reflection reaching even C++23 is pretty low. > > Considering that there's already implementation experience on both > introspective reflection > and code generation, it's safe to say that that's far from a matter of > fact. > Sure, that's possible. But the statistical evidence from the committee's behavior strongly suggests otherwise. Concepts took about 4 years to go from initial design to a finished TS. While there had been some talk about modules before N4047 in 2014, it still took 3 years to take that proposal to the PDTS phase, putting it on Concepts TS's pace. The Coroutines TS took even longer, finally landing as a TS after 6 years work. Introspective reflection? That started in 2014, and they're still arguing about the interface. Don't get me wrong; that's a good argument to have. I'm just saying that it's moving slowly much more slowly than other proposals. It's looking more on pace to match Coroutines than Concepts. And that's just measuring the time to becoming a TS. If you look at the TS wave that entered C++17, we clearly see that the only things that made it were things that reached their TS status by the end of 2014. Filesystem, Parallelism v1, and LibFundamentals v1 all hit that timeframe, and they all got voted in. Concepts, and Concurrency missed that timeframe and had to wait for the next C++ version. You could argue that there were technical reasons for waiting on those. But this is what we've seen from the committee. Concepts, Ranges, Networking, and Coroutines are probably going to hit C++20. But Modules is on the same timeframe relative to C++20 that Concepts were relative to C++17. And purely introspective reflection is even farther behind than that. So unless the intent is to have the various reflection proposals go straight into the standard without a TS phase first, I don't see a reason to expect reflection of any form to be standardized anytime soon. So while I appreciate your optimism about the committee's ability to quickly adopt features, until there is evidence of that optimism translating into features actually being quickly adopted, I shall remain skeptical ;) > If mixins are a good idea for C++, I just don't see a need for us to hold > > off until C++23 (at the earliest), just because we think we might be > able to > > get them via code generation reflection. If it were right around the > corner, > > that'd be one thing. But when that sort of stuff is still in the > > design/research project stage, then let's see if we can solve the > problem in > > a more direct way. > > At least in the meantime. > > If we'd have a pressing need for mixins, or confidence that we can't > get close enough > to them via the reflection facilities, that might be plausible. > Neither being the case, there's > no need to rush into a specific mixin facility. > Every time you use the CRTP, what you're really doing is using a mixin. So the Range-v3 technique for creating range types easily? That's just a mixin, done in a very unintuitive way. The need for this feature has been there for quite some time. The need for it as a language feature is to avoid all of the problems associated with it as an idiom (teachability, fragile interface, no compiler checking, etc). -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7fe1d0c9-79b0-4e18-919a-be56fd102892%40isocpp.org. ------=_Part_1237_1511278969.1502392333029 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, August 10, 2017 at 1:38:25 PM UTC-4, Ville Vo= utilainen wrote:
On 10 August 2= 017 at 20:14, Nicol Bolas <jmck...@gmail.com> wrote:
> I guess it's more a matter of the fact that it's a very fa= r future thing.
> C++20 is highly unlikely to see purely introspective reflection. S= o the
> chance of code generation reflection reaching even C++23 is pretty= low.

Considering that there's already implementation experience on both
introspective reflection
and code generation, it's safe to say that that's far from a ma= tter of fact.

Sure, that's possible. But the s= tatistical evidence from the committee's behavior strongly suggests oth= erwise.

Concepts took about 4 years to go from initial design to a f= inished TS.=20 While there had been some talk about modules before N4047 in 2014, it still= took 3 years to take that proposal to the PDTS=20 phase, putting it on Concepts TS's pace. The Coroutines TS took even lo= nger, finally landing as a TS after 6 years work.

Introspective refl= ection? That started in 2014, and they're still arguing about the inter= face. Don't get me wrong; that's a good argument to have. I'm j= ust saying=20 that it's moving slowly much more slowly than other proposals. It's= looking more on pace to match Coroutines than Concepts.

And that= 9;s just measuring the time to becoming a TS. If you look at the TS wave th= at entered C++17, we clearly see that the only things that made it were thi= ngs that reached their TS status by the end of 2014. Filesystem, Parallelis= m v1, and LibFundamentals v1 all hit that timeframe, and they all got voted= in. Concepts, and Concurrency missed that timeframe and had to wait for th= e next C++ version.

You could argue that there were technical reason= s for waiting on those. But this is what we've seen from the committee.=

Concepts, Ranges, Networking, and Coroutines are probably going to = hit C++20. But Modules is on the same timeframe relative to C++20 that Conc= epts were relative to C++17. And purely introspective reflection is even fa= rther behind than that.

So unless the intent is to have the various = reflection proposals go straight into the standard without a TS phase first= , I don't see a reason to expect reflection of any form to be standardi= zed anytime soon.

So while I appreciate your optimism about the comm= ittee's ability to quickly adopt features, until there is evidence of t= hat optimism translating into features actually being quickly adopted, I sh= all remain skeptical ;)

> If mixins are a good idea for C++, I just don't see a need for us = to hold
> off until C++23 (at the earliest), just because we think we might = be able to
> get them via code generation reflection. If it were right around t= he corner,
> that'd be one thing. But when that sort of stuff is still in t= he
> design/research project stage, then let's see if we can solve = the problem in
> a more direct way.
> At least in the meantime.

If we'd have a pressing need for mixins, or confidence that we can&= #39;t
get close enough
to them via the reflection facilities, that might be plausible.
Neither being the case, there's
no need to rush into a specific mixin facility.

Every time you use the CRTP, what you're real= ly doing is using a mixin. So the Range-v3 technique for creating range typ= es easily? That's just a mixin, done in a very unintuitive way.

= The need for this feature has been there for quite some time. The need for = it as a language feature is to avoid all of the problems associated with it= as an idiom (teachability, fragile interface, no compiler checking, etc).<= br>

--
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/7fe1d0c9-79b0-4e18-919a-be56fd102892= %40isocpp.org.
------=_Part_1237_1511278969.1502392333029-- ------=_Part_1236_686147625.1502392333028-- .