220 25030 <840b1f9a-be05-4454-b20d-99e2ccb3c1f1@isocpp.org> article Path: news.gmane.org!not-for-mail From: Cleiton Santoia Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "Components" template with implicitly defined partial specializations for all classes Date: Mon, 7 Mar 2016 09:26:01 -0800 (PST) Lines: 187 Approved: news@gmane.org Message-ID: <840b1f9a-be05-4454-b20d-99e2ccb3c1f1@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3933_1126998797.1457371562067" X-Trace: ger.gmane.org 1457371580 12757 80.91.229.3 (7 Mar 2016 17:26:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 17:26:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCBMVWMTUUNBBK7T623AKGQEOV6WGWQ@isocpp.org Mon Mar 07 18:26:13 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1acyv4-0002Na-6C for gclcip-std-proposals@m.gmane.org; Mon, 07 Mar 2016 18:26:10 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id wz1sf155462370obc.3 for ; Mon, 07 Mar 2016 09:26:04 -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=EboRO1DcUkJQJm6hLm+MxZbGPxqHxt3iQoW7jbraFtQ=; b=nf6CVE2gF7B+NiXIYmMld6d/Fy6EjCVYXwRMZZ6wRaBiT2N0zGgmjsYF8Vgdsq7G+f LhmF5q7AnhFnKCsX8MHtsGPFU1cEttWzaXbRZO2TbYMaU1BVVUZBH3RWydzr+VK4Rt6o IqqF1T5UoMctBbtjsKw0c/lOVBiGPts2WLB5XhH0kTjkYzKLRoDs33j2C7sEksqwialS vrI6o+EHCCel4xEehScqKqb74xaXRfqp7CnhfL4hlwGfvDWOkQqxGA3wI9heQzMffnZf CevxKuqMEWrVLPpFgQ9/PAhZnFgH/fVEXuCaDE8Yov9F6CdE0D0Yzrhxofmsc91eSdcr mQ4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=EboRO1DcUkJQJm6hLm+MxZbGPxqHxt3iQoW7jbraFtQ=; b=qzJkLZGiV/aRrcIHcDcZjo4MFDuKlzmUyUwCRvx4NdujnEsTCh6oLPYFLcx3AD0zcE NkxGqYh2Sy0kQ5LEc7oLKcx42mM/qkKETtDIqwFhDOtopSkmSgCgJH6U3h0qEJs0s7KC a4h+xZha91B+KpM3F4BdE/mvn0+AHs7bpmbw/AkdxHJ+GasS7ZnBms3XFaU2FRlCC6Ry OuZC6RORilcRTNR/bzpdO+ExRNYO5eND05g0Z2mr0m7DdzlW/4vQivV3RkQMd0Yid1aJ VXtZ9gamFJkQhxuWx5tLSn/MU4RFrpOWXWLx3+Vaj9jHjksJwvsftT+hmrl8dohrlzU0 a8sw== 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=EboRO1DcUkJQJm6hLm+MxZbGPxqHxt3iQoW7jbraFtQ=; b=RV8P83BVNSdrc1Wf0K67mjFMq5QwZl9OVHz9+f9dYe/tUJBfgUlsJt2eWzBm0ONmT1 mHgpxjEqMERF389seFQECzsF/+bF14n03LFvn+oBl73eYy09o6tdEDyiyYt56t1BiQV8 19wi42LrbcnNShAa7KwndBXo016r+RVehpSqamihqh4ELXveymsCchcV2u3bj/UBE9MH tAVuX+AnGKnaP6R6S1zyya93rF5vG10ozaOChBkdOuMzk78uqT3ry4ZZY9TBtc038soV CNzusBIqTDsHQXr07ojdmBrs+1z/joomIG7GZHlSubOzEbjZvNY9yCEUZ4ZjDcD5Ic0+ pnLA== X-Gm-Message-State: AD7BkJL+lfXgRsEao+vxMKxvZEmZvqJXGs1VupJ5dn4EOiD15l1Gt9+O5/6eQDtB2Sj01A== X-Received: by 10.107.184.195 with SMTP id i186mr17903587iof.24.1457371564354; Mon, 07 Mar 2016 09:26:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.167.14 with SMTP id q14ls1005530ioe.44.gmail; Mon, 07 Mar 2016 09:26:03 -0800 (PST) X-Received: by 10.50.25.196 with SMTP id e4mr227514igg.8.1457371563104; Mon, 07 Mar 2016 09:26:03 -0800 (PST) In-Reply-To: <56DD28C8.7020708@wanadoo.fr> X-Original-Sender: cleitonsantoia@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:25030 Archived-At: ------=_Part_3933_1126998797.1457371562067 Content-Type: multipart/alternative; boundary="----=_Part_3934_1432170408.1457371562067" ------=_Part_3934_1432170408.1457371562067 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Em segunda-feira, 7 de mar=C3=A7o de 2016 04:07:54 UTC-3, Vicente J. Botet= =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 that= =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 somehow= =20 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 become= =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 compilation= =20 unit can see. And don't get me started with modules.... BR CSS --=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/840b1f9a-be05-4454-b20d-99e2ccb3c1f1%40isocpp.or= g. ------=_Part_3934_1432170408.1457371562067 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Em segunda-feira, 7 de mar=C3=A7o de 2016 04:07:54= UTC-3, Vicente 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

--
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/840b1f9a-be05-4454-b20d-99e2ccb3c1f1= %40isocpp.org.
------=_Part_3934_1432170408.1457371562067-- ------=_Part_3933_1126998797.1457371562067-- .