220 39705 article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why are concepts restricted to namespace-scope? Date: Sat, 11 Aug 2018 08:26:29 -0700 (PDT) Lines: 213 Approved: news@gmane.org Message-ID: References: <3825544b-b617-4a0e-a02d-a5041d989c15@isocpp.org> <93c917bb-1c8d-405d-80e9-4fe036af1a58@isocpp.org> <0b82cc47-9dd1-41f1-80b4-3e1469aaa9a9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1086_1914637698.1534001189660" X-Trace: blaine.gmane.org 1534001065 21326 195.159.176.226 (11 Aug 2018 15:24:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Aug 2018 15:24:25 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBJUAXTNQKGQEO2KEWXQ@isocpp.org Sat Aug 11 17:24:21 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1foVka-0005Sq-V6 for gclcip-std-proposals@m.gmane.org; Sat, 11 Aug 2018 17:24:21 +0200 Original-Received: by mail-yw1-f71.google.com with SMTP id z83-v6sf16979511ywg.3 for ; Sat, 11 Aug 2018 08:26:31 -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=fgZ1qysI9LmUrZZ8GxpiyXPozaNVELhyihTO8NT9y4g=; b=kIj2m5GQXC4+qDY/gclk2Y0UfrFya2mdrk87VmbNWhpEgNK1GXn2i5QNYIia/q7BOJ nvXMsxLpUqITYppQgRlW+Ulp7Vh81KzzNuUv4KGQPqGd07mjk+QAL4yN7ScmfS+SOFxs 4e06oAAOGbvJLmaM4mPpP8JZEvQGzu6qqu/joUiCn4VFochgqaghrSk4144HOchRCvYJ Gy3AOEIvkc2ZNm/s6J+X1oBZSNLe1ZNB67oFTf++A7du5shY/ay25jgAx/uGdwgSOZg9 4y7E9mf4CkVnoAqILgfWgq5+Qrb/+tnWI7bRu4RbSYqyBDLqyazV5t1tMevwsyhWV8tL EaXQ== 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=fgZ1qysI9LmUrZZ8GxpiyXPozaNVELhyihTO8NT9y4g=; b=LvmObMT6DdTStkhXWuduZ1tK/GVJODvP06dkYIFOqgUXwEeJLwalUGHgJBB2LKbkpD zihGTyslMHevEmrKh3qwH5tX2K1Wh5/0x0VnZrkg91VpoWB0ji6sR7NvWqpBgxDBYCsc KXCkaMtE4LB2q0kpM0zlQ5OCnb0RKxKfJP97cwuE5vHXXea+p+um5FLIaYhQs52GyW15 lRSU4PUuA8/r6qrp7CcNMEFCa2Wd03cEcDftdDW3i1KfndUURvZrTZaGL20m6X6+TZBw /YMccnInuCnL/f1SSKaOkAzZA3T4gflAgjZP2hUGjKld3pulZ7CTFRNbasxxR1fSFmf/ bDxg== 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=fgZ1qysI9LmUrZZ8GxpiyXPozaNVELhyihTO8NT9y4g=; b=hQTaSVrsBEcDBOBzWLUa2LzFzeJK3YMlfaqHISQYXT7AHPm2mj0GtVUBUqTxIqIQnT Dpf7Gt3w28bmy65ljcHUMt2918zvwejzU5nsgOTmhYSCTi0oKSKv1+2KBjJ0GKJRIuzK 5hrOevwV6RWV6SiJiQCBrRDtaRtpyYmlYfIwVd418W33v7oBODoUcktnVyRUi/gp9YnD ltvve7kkWk9WkLcNcKmowL99G4HC6g/5WdWbpA8+a0GVNtLybtRBaCfhGFOn73hLOBZV 3MDrvKG2/8MN6d35q63XQoYdUlTNXzpkKxYZgQ7sks1W1ZkU25peVD3iW6+qwM5nEvRc fYYw== X-Gm-Message-State: AOUpUlGnrFCiwlbxi8HwUpbKBI/D830zvwv7aqaBJFqqqvs3VbVI5xXq rB8xUlSUqusZWilMkVTTpmHmyw== X-Google-Smtp-Source: AA+uWPxPek0OF+LSYSAuzn0oS4QqwfNI6sUeDAM71g+5imBg1Ng0juuMjb1Cy7U9PbH8pYg4+ArRbQ== X-Received: by 2002:a81:1786:: with SMTP id 128-v6mr3494622ywx.176.1534001191318; Sat, 11 Aug 2018 08:26:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:a08f:: with SMTP id x137-v6ls1925185ywg.37.gmail; Sat, 11 Aug 2018 08:26:30 -0700 (PDT) X-Received: by 2002:a81:78c6:: with SMTP id t189-v6mr246896ywc.7.1534001190098; Sat, 11 Aug 2018 08:26:30 -0700 (PDT) In-Reply-To: X-Original-Sender: florian.csdt@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:39705 Archived-At: ------=_Part_1086_1914637698.1534001189660 Content-Type: multipart/alternative; boundary="----=_Part_1087_1012918463.1534001189661" ------=_Part_1087_1012918463.1534001189661 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le samedi 11 ao=C3=BBt 2018 17:18:47 UTC+2, Nicol Bolas a =C3=A9crit : > > On Saturday, August 11, 2018 at 9:14:45 AM UTC-4, Bengt Gustafsson wrote: >> >> >>> That's an excellent reason to not permit this. Constraint normalization= =20 >>> and subsumption checking operate on the concept's definition *before*= =20 >>> instantiation, and so rely on a concept having a single unique definiti= on.=20 >>> If you can have arbitrarily many definitions for what appears to be the= =20 >>> same concept, how exactly do you normalize it and check for subsumption= ? >>> >> >> I don't think this is a valid concern. A concept inside a class would=20 >> have to be accessed using Class::theConcept, and in doing so the= =20 >> actual template parameters are already known. >> Obviously MyType can be a dependant type if the concept is used in=20 >> template code, but at the time of template instantiation the actual valu= e=20 >> of MyType will be known anyway. >> >> As in my example above it seems reasonable to believe that the main use= =20 >> of concepts in classes would be to specify characteristics of parameters= to=20 >> template functions in the same class. It does not seem important to defi= ne=20 >> a concept in a class if it is not used as requirements in its own method= s=20 >> or nested classes.=20 >> > >> Someone rasied the objection that we should not allow concepts in classe= s=20 >> because we can't find a use case for it. I totally disagree with this id= ea.=20 >> Finding interesting uses for a feature is a main driver for innovation. = If=20 >> we didn't have SFINAE we might not have worked so hard to get concepts t= o=20 >> get a better implementation of that type of overload selection. >> > > I disagree with that. Without SFINAE, we would still have a genuine need= =20 > for concepts. Indeed, without SFINAE, we would have more of a need, since= =20 > we'd have to employ even more complex, expert-only ways of doing that kin= d=20 > of stuff. > > If we had had variable templates from the beginning we would not have to= =20 >> write _v on all our type traits now.=20 >> > Template variables were excluded from C++98 because Bjarne didn't see any= =20 >> use for them (he stated this in a private mail to me long time ago). >> > > You've been using C++11 for too long. Bjarne was right; variable template= s=20 > in C++98 were not useful. > > Variable templates are not useful by themselves; what makes them useful i= s=20 > a combination of language features. Specifically, `constexpr` and `inline= `=20 > variables. Without both of those features, you wouldn't really be able to= =20 > replace type traits with variable templates. So we'd have still had to wa= it=20 > until C++17. > > I get the general thrust of what you're saying. But my point is that all= =20 > of those possible uses for class-scoped concepts are either minor=20 > conveniences (scoping the name) or things that should be done with *actua= l=20 > features*, not hacks and kludges that manage to accomplish a useful=20 > effect. C++ is being updated with greater frequency now than in the C++98= =20 > days. We don't need to allow everything on the assumption that someone=20 > might find a use for it. We can do "enough" and then expand next time if = a=20 > genuine need emerges. > I would agree if allowing this would make the language more complicated.=20 Here, it is the opposite. It would make the language simpler as there would= =20 be less corner cases. Don't get me wrong, I'm not saying we should allow it. But I'm saying that= =20 this argument doesn't really hold here (unless you can show that it would= =20 be actually more complicated). =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/fa758945-3bdd-423f-b7be-e8927cf8b9f5%40isocpp.or= g. ------=_Part_1087_1012918463.1534001189661 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le samedi 11 ao=C3=BBt 2018 17:18:47 UTC+2, Nicol = Bolas a =C3=A9crit=C2=A0:
On Saturday, August 11, 2018 at 9:14:45 AM UTC-4, Bengt Gustafs= son wrote:

That&#= 39;s an excellent reason to not permit this. Constraint normalization and s= ubsumption checking operate on the concept's definition *before* instan= tiation, and so rely on a concept having a single unique definition. If you= can have arbitrarily many definitions for what appears to be the same conc= ept, how exactly do you normalize it and check for subsumption?
=

I don't think this is a valid concern.= A concept inside a class would have to be accessed using Class<MyType&g= t;::theConcept, and in doing so the actual template parameters are already = known.
Obviously MyType can be a dependant type if the concept is= used in template code, but at the time of template instantiation the actua= l value of MyType will be known anyway.

As in my e= xample above it seems reasonable to believe that the main use of concepts i= n classes would be to specify characteristics of parameters to template fun= ctions in the same class. It does not seem important to define a concept in= a class if it is not used as requirements in its own methods or nested cla= sses.

Someone rasied the objection that we = should not allow concepts in classes because we can't find a use case f= or it. I totally disagree with this idea. Finding interesting uses for a fe= ature is a main driver for innovation. If we didn't have SFINAE we migh= t not have worked so hard to get concepts to get a better implementation of= that type of overload selection.

I disagree with that. Without SFINAE, we would still have a genuine need= for concepts. Indeed, without SFINAE, we would have more of a need, since = we'd have to employ even more complex, expert-only ways of doing that k= ind of stuff.

If we had had variable templates from the beginnin= g we would not have to write _v on all our type traits now.
Template variables were excluded from C++98 because Bjarne didn't see = any use for them (he stated this in a private mail to me long time ago).

You've been using C++11 for t= oo long. Bjarne was right; variable templates in C++98 were not useful.

Variable templates are not useful by themselves; what= makes them useful is a combination of language features. Specifically, `co= nstexpr` and `inline` variables. Without both of those features, you wouldn= 't really be able to replace type traits with variable templates. So we= 'd have still had to wait until C++17.

I get t= he general thrust of what you're saying. But my point is that all of th= ose possible uses for class-scoped concepts are either minor conveniences (= scoping the name) or things that should be done with actual features= , not hacks and kludges that manage to accomplish a useful effect. C++ is b= eing updated with greater frequency now than in the C++98 days. We don'= t need to allow everything on the assumption that someone might find a use = for it. We can do "enough" and then expand next time if a genuine= need emerges.

I would agree if= allowing this would make the language more complicated. Here, it is the op= posite. It would make the language simpler as there would be less corner ca= ses.

Don't get me wrong, I'm not saying we= should allow it. But I'm saying that this argument doesn't really = hold here (unless you can show that it would be actually more complicated).=
=C2=A0

--
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/fa758945-3bdd-423f-b7be-e8927cf8b9f5= %40isocpp.org.
------=_Part_1087_1012918463.1534001189661-- ------=_Part_1086_1914637698.1534001189660-- .