220 25033 <390f2de7-6ab3-47cc-b76c-a7454dec5fc5@isocpp.org> article Path: news.gmane.org!not-for-mail From: "'Walt Karas' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "Components" template with implicitly defined partial specializations for all classes Date: Mon, 7 Mar 2016 11:25:49 -0800 (PST) Lines: 233 Approved: news@gmane.org Message-ID: <390f2de7-6ab3-47cc-b76c-a7454dec5fc5@isocpp.org> References: <56D9E17F.2070202@wanadoo.fr> <2b0bcca0-0939-49f7-939b-4d688f8dfe34@isocpp.org> <324dbff9-84da-46f2-b2f3-3d9fe0cc2082@isocpp.org> <56DA88DF.90000@wanadoo.fr> <7e46c46d-2e18-4cec-92c1-4f4d7fbc786b@isocpp.org> <39bbeb02-62b8-497b-8d65-5780a6baca97@isocpp.org> <05ac78e7-3d30-4a99-ad0f-a3d29497e2ff@isocpp.org> <2c7cb187-ad83-4ceb-af8b-1e61d4fb4d0d@isocpp.org> <56DD28C8.7020708@wanadoo.fr> <840b1f9a-be05-4454-b20d-99e2ccb3c1f1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14_2075233692.1457378749524" X-Trace: ger.gmane.org 1457378759 6661 80.91.229.3 (7 Mar 2016 19:25:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 19:25:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDFLZXWOVYIBBPVL663AKGQEVQSRZWA@isocpp.org Mon Mar 07 20:25:59 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f71.google.com ([209.85.192.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ad0mu-0006H6-Nd for gclcip-std-proposals@m.gmane.org; Mon, 07 Mar 2016 20:25:53 +0100 Original-Received: by mail-qg0-f71.google.com with SMTP id p68sf135279176qge.3 for ; Mon, 07 Mar 2016 11:25:52 -0800 (PST) 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=e1i1vd1tEISxDcUsDbi1qG0tN7ICTLAbGWmVX4bKkMc=; b=fkm4utM2fjqkSEPlH+KWstyBAih5MVY65s3qMTj7UJzCeK5AYJB5Mfb8i6397sys7Q PKOX4gTOgbJPZnXriSmg/MLt7JagSX1QfQrSbcesH8ZEeILk93T5IwqaiRcBOxaUqzHc h+nQAaTokwNcxWezSPzqymN18pt22r4ig4aCC984fj+oYwn+J5KlAXInSE4qt3WcGOGw zLfyg+Uo2WpQQ57+U+PbqGqcdu65gz5FR3Ev5Ngh7ugijk6dZ12aBrUfw1gVW+3JDu3b RLpy6/EHWL90/Nr32Y2Q4IBmUumFDxo3RXtlc5lmMpYed/HYvL2qoa1jIQUhx3SDDwPe 6Twg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=e1i1vd1tEISxDcUsDbi1qG0tN7ICTLAbGWmVX4bKkMc=; b=KiR0l7YVE8SgU5DYnB/zUYH4EKnDuJwICSlqvl/f1B1OWJ8w1xJPpsht48PimwRcYU eI7pfMJJgHi49mwsKwdtAIjn2L6gvmwjXatd2Lv+lBEsDlO/gP2L91l0X0oAhsmIlNuO KLM7KDEU6AGtFxI6r6SlvstKqPYsJF6aK23U7DZNnJfCD35G9CB/zp0HhgqXlsXLgNZH DbGF0HQ+N4iMZISc7RIXr5wCLaKHWRrXSvJRECMl5AEU4ZtwZfjoCNW3l5M8F6KVTbUq 3GnY4smuoclA2trhzABlNai5VSSMwPnLVxfWgO5PeF0bHc7Dj+w3R364mKZDUUgwaiX2 Q62A== X-Gm-Message-State: AD7BkJLg27xlm4R14NhyaW2G+1Wiox963pNPZsJAKDHsk3EC6LmzC7sY0xDRpxhUKnEiMQ== X-Received: by 10.129.78.78 with SMTP id c75mr9382243ywb.30.1457378751583; Mon, 07 Mar 2016 11:25:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.79.197 with SMTP id l5ls972225igx.31.gmail; Mon, 07 Mar 2016 11:25:50 -0800 (PST) X-Received: by 10.50.25.196 with SMTP id e4mr246076igg.8.1457378750529; Mon, 07 Mar 2016 11:25:50 -0800 (PST) In-Reply-To: <840b1f9a-be05-4454-b20d-99e2ccb3c1f1@isocpp.org> X-Original-Sender: wkaras@yahoo.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: , X-Original-From: Walt Karas Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:25033 Archived-At: ------=_Part_14_2075233692.1457378749524 Content-Type: multipart/alternative; boundary="----=_Part_15_1267560024.1457378749525" ------=_Part_15_1267560024.1457378749525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 7, 2016 at 12:26:02 PM UTC-5, Cleiton Santoia wrote: > > > > Em segunda-feira, 7 de mar=C3=A7o de 2016 04:07:54 UTC-3, Vicente J. Bote= t=20 > Escriba escreveu: >> >> Le 07/03/2016 04:16, Cleiton Santoia a =C3=A9crit : >> >> >>> >>> Can you show an example that would work also if the class had private= =20 >>> data members and base classes?=20 >>> >> >> >> Case 1 private : =20 >> typedef=20 >> >> >> >> Do you mean that this will not need any friend annotation? >> >> Vicente >> > > In my proposal yes... no annotation, but that it is far from consensus in= =20 > SG7, the last big discussion about it was in urbana ( sorry I don't know= =20 > about jacksonsville yet ) and the SG7 asked few things: > > 1 Private access must be provided, but not "accidentally" or "by default"= =20 > you must explicitly ask for it. > 2 You should not change the class or members under reflection to become= =20 > reflective, so you must be able to reflect classes (possibly old) without= =20 > changing them. > 3 Even with "outsider" private access, you must have a way to protect=20 > "vendor private code" like some compiler intrinsic or some dark corner th= at=20 > the vendor don't want or it=C2=B4s not safe to you to look at. =20 > > But I think (IMO) none of them are "written in stone", I think that=20 > somehow we will face exceptions to this "rules" if it has some advantage. > > This leads to few ( both strange ) alternatives > > A- > 1 - by default you don't get access to private !=20 > 2 - you annotate something [[look_at_me]] in the private part so it becom= e=20 > reflectible. ( going against Rule 2 ) > > B- > 1 - by default you dont get access to private ! > 2 - but if you ask for "is_private" ( or something like that ) you get=20 > private access, unless... > 3 - you write something in the class [[dont_look_here]] annotation to=20 > forbid private access. ( also going against Rule 2 )=20 > > And also remember that this access is constrained by what your compilatio= n=20 > unit can see. > And don't get me started with modules.... > > > BR > CSS > In the example you gave for a generic =3D=3D operator, the equals_helper=20 template function could be wrapped in a helper class. A class with=20 non-public data components could friend the helper class if the generic=20 operator was correct for it. In a sense, the default constructors,=20 destructor and assignment operator are all reinventions of the "foreach=20 component reflection" wheel. We can continue the multiple reinventions for= =20 the comparison operators (also a violation of strictest respect for access= =20 control). Or (assuming that friending a helper class works in general)=20 classes with non-public data components can acknowledge library default=20 functions and operators with a single simple friend declaration. Lobbyists= =20 for companies wanting to sell library include file upgrades will wine and= =20 dine the Committee in support of this. Since you mention an is_base predicate, I assume that means you have some= =20 sort of member pointer to a base class, but I see no explicit discussion of= =20 that.=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/390f2de7-6ab3-47cc-b76c-a7454dec5fc5%40isocpp.or= g. ------=_Part_15_1267560024.1457378749525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, March 7, 2016 at 12:26:02 PM UTC-5, Cle= iton Santoia wrote:


Em segunda-feira, 7 de mar=C3=A7o de 2016 04:07:54 UTC-3, Vic= ente J. Botet Escriba escreveu:
=20 =20 =20
Le 07/03/2016 04:16, Cleiton Santoia a =C3=A9crit=C2=A0:


Can you show an example that would work also if the class had private data members and base classes?=C2=A0


Case 1 private : =C2=A0
typedef<C, is_private>



Do you mean that this will not need any friend annotation?

Vicente

In my proposal yes...= no annotation, but that it is far from consensus in SG7, the last big disc= ussion about it was in urbana ( sorry I don't know about jacksonsville = yet ) and the SG7 asked few things:

1 Private acce= ss must be provided, but not "accidentally" or "by default&q= uot; you must explicitly ask for it.
2 You should not change the = class or members under reflection to become reflective, so you must be able= to reflect classes (possibly old) without changing them.
3 Even = with "outsider" private access, you must have a way to protect &q= uot;vendor private code" like some compiler intrinsic or some dark cor= ner that the vendor don't want or it=C2=B4s not safe to you to look at.= =C2=A0

But I think=C2=A0(IMO)=C2=A0none of them a= re "written in stone", I think that somehow we will face exceptio= ns to this "rules" if it has some advantage.

=
This leads to few ( both strange ) alternatives

A-
1 - by default you don't get access to private !=C2=A0<= /div>
2 - you annotate something [[look_at_me]] in the private part so = it become reflectible. ( going against Rule 2 )

B-=
1 - by default you dont get access to private !
2 - bu= t if you ask for "is_private" ( or something like that ) you get = private access, unless...
3 - you write something in the class [[= dont_look_here]] annotation to forbid private access. ( also going against = Rule 2 )=C2=A0

And also remember that this access = is constrained by what your compilation unit can see.
And don'= ;t get me started with modules....


<= div>BR
CSS

In the example you ga= ve for a generic =3D=3D operator, the equals_helper template function could= be wrapped in a helper class.=C2=A0 A class with non-public data component= s could friend the helper class if the generic operator was correct for it.= =C2=A0 In a sense, the default constructors, destructor and assignment oper= ator are all reinventions of the "foreach component reflection" w= heel.=C2=A0 We can continue the multiple reinventions for the comparison op= erators (also a violation of strictest respect for access control).=C2=A0 O= r (assuming that friending a helper class works in general) classes with no= n-public data components can acknowledge library default functions and oper= ators with a single simple friend declaration.=C2=A0 Lobbyists for companie= s wanting to sell library include file upgrades will wine and dine the Comm= ittee in support of this.

Since you mention an is_base predicate, I = assume that means you have some sort of member pointer to a base class, but= I see no explicit discussion of that.

--
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/390f2de7-6ab3-47cc-b76c-a7454dec5fc5= %40isocpp.org.
------=_Part_15_1267560024.1457378749525-- ------=_Part_14_2075233692.1457378749524-- .