220 29971 article Path: news.gmane.org!.POSTED!not-for-mail From: Eugenio Bargiacchi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A strong typedef syntax idea Date: Wed, 21 Dec 2016 13:41:28 +0100 Lines: 461 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1143b094cc480405442a786b X-Trace: blaine.gmane.org 1482324106 6231 195.159.176.226 (21 Dec 2016 12:41:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Dec 2016 12:41:46 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCWJHLVBTMARB6XQ5HBAKGQESJA6QCA@isocpp.org Wed Dec 21 13:41:37 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f69.google.com ([74.125.83.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJgD1-0007Xy-30 for gclcip-std-proposals@m.gmane.org; Wed, 21 Dec 2016 13:41:27 +0100 Original-Received: by mail-pg0-f69.google.com with SMTP id f188sf561613999pgc.1 for ; Wed, 21 Dec 2016 04:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=ufHNhDx/5lQRM1EuFYn2ZKvNNyYXcFdS8qQG9QJVfys=; b=GG3gyvslqwHN2zKfCn9poePJESTengTKQrjloRQ2m7I4TGus752NkNK4Hf3Q85Y0Xo wT639S/X5P/gaBM+xJYazEOEd7X9InVJhFCB7hsJDcDXsvPYXdTI5Fm4eYWNSv1nnaWh lNGaOeQsRWkUtRUUC1geapK/bad5klDnPZ8mvhlMfZCPRkpBS9/u2pexuIrmK1p6ePr9 IHjDdDpmNgQvyKRBgYtxImguxSTLxnclu1p94vq9HT+iKG6jdISDIITTdzhlZRMuiK09 tTeX+lUMC+rfczRpEK2Qm+nUX3rwcrHgQtDyY+XrKkS63cT5TeXAxyhah6knkyrTfA2+ UtOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ufHNhDx/5lQRM1EuFYn2ZKvNNyYXcFdS8qQG9QJVfys=; b=uTnYlguRfoSd3r4cp9JUghxPGHEK5jjaEtRFswiejZjGoZUahBuwf3zeEt46DggFld b4HDcX7WpcTUkoLrK2LusTJDxsrmKjcgYIQXKC4iEATjhfu/o/gkyxHr8gm0CZXqeuds RzutMGINsoIuKPvggfCISc775mZlqzfhp530ybDZ6a7qxdWbtM90/PveiLmFuPBxTceh 71DeDKOXXZBkIMednzj7NXlmRh7U3ZXdIyJEcThVIqWwDHSQqBv/ENmLr/ilqnl7g9Dw 4xqz9OUmouNeesepNbg7JfloyqavJKXtDvG0URqmvSK2rqYk2PHf7RV1cWgyWMUAXCp/ vO5g== X-Gm-Message-State: AIkVDXIVO2wlgohWnotibC4mQriBdHHGTgihTxcJEzDzM1JqwPdMWjl5hwDghTfqbtkBkQ== X-Received: by 10.99.99.133 with SMTP id x127mr2345989pgb.58.1482324091129; Wed, 21 Dec 2016 04:41:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.46.204 with SMTP id w70ls1407674ota.41.gmail; Wed, 21 Dec 2016 04:41:30 -0800 (PST) X-Received: by 10.176.69.71 with SMTP id r65mr2821580uar.77.1482324090059; Wed, 21 Dec 2016 04:41:30 -0800 (PST) Original-Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com. [2607:f8b0:400c:c05::22f]) by mx.google.com with ESMTPS id 106si6764065uav.232.2016.12.21.04.41.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 04:41:30 -0800 (PST) Received-SPF: pass (google.com: domain of svalorzen@gmail.com designates 2607:f8b0:400c:c05::22f as permitted sender) client-ip=2607:f8b0:400c:c05::22f; Original-Received: by mail-vk0-x22f.google.com with SMTP id 137so149260390vkl.0 for ; Wed, 21 Dec 2016 04:41:30 -0800 (PST) X-Received: by 10.31.10.212 with SMTP id 203mr1780621vkk.5.1482324089520; Wed, 21 Dec 2016 04:41:29 -0800 (PST) Original-Received: by 10.31.227.133 with HTTP; Wed, 21 Dec 2016 04:41:28 -0800 (PST) In-Reply-To: X-Original-Sender: svalorzen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of svalorzen@gmail.com designates 2607:f8b0:400c:c05::22f as permitted sender) smtp.mailfrom=svalorzen@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:29971 Archived-At: --001a1143b094cc480405442a786b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bengt, I understand it may get a bit complicated. Replacements are actually a feature that I proposed just to get it considered. I believe the feature should allow to add new methods/features to a class; substituting/deleting existing functionality is more complicated but it could have its use cases and would allow to make better use of existing class implementations, so that's why I added it for considerations. About the part on interdependent classes I have written that the classes should be "defined" as copies of their aliased equivalent. Not sure if the compiler can handle it in one pass, or if there is a better way to state that requirement. I believe that making strong typedefs in general is important, and not only for primitive types. Sure making them on primitive types only would still be an improvement, but there are many compelling use-cases for also making strong typedefs of classes, for example in scientific fields. I have added in my examples copy constructors and the like since they are considered heavily in the already existing proposals, and they state that requirements were gathered after extensive discussions with many potential users. It's definitely not a requirement to add them, I just wanted to show how it could be done since it could be needed. Jo=C3=ABl, about copy I feel the same way. I'll try to work out a nicer terminology. About internal classes, this is a very good question. Actually I realized yesterday that another thing which could be hard to define correctly would be how to treat `friend` declarations. A relatively simple solution would be that all names that depend on the original name are copied, while those that don't are not ported over (for example friend method declarations/definitions). So in your example A::Impl would be copied into B::Impl. However, in this example: void bar() {} struct A { friend int foo(A) { return 0; } friend void bar(); }; struct B : using A {}; Nothing would be copied, since the functions `foo` and `bar` do not depend directly on the original type. If needed, a different `int foo(B)` can be separately implemented by the copier. It's not exactly intuitive, but I believe it would be better, otherwise copying everything defined "internally" could lead to recursive copying of many things which one would not expect copied. About symbols, personally I think they should work as if the user had written the new class by hand, if possible. This should keep the rules relatively simple, as a user can always create a new copy of a class by hand (one cannot do inheritance by hand, for example, as the language gives guarantees about it not achievable by writing a new class from scratch). I would say alignof/as would be kept. The same for existing typedefs. The idea here is to offer a certain amount of customizations of classes that are copied, but not too much - otherwise it would be best for the user to just create the new type by hand. The line must be drawn somewhere, and I'd prefer the feature to be simple rather than having to define how to take apart an existing type. Ideally the feature would be more constructive than destructive, as in first define types, and each copy adds stuff, rather than start with a big type and remove things from it. Having the possibility to remove things however gives space to make better use of existing classes, and that's why I included it. Best, Eugenio On Wed, Dec 21, 2016 at 10:03 AM, Klaim - Jo=C3=ABl Lamotte wrote: > Hi, > This is an interesting proposal. > May I suggest you change your "copy" word usage for something else or mor= e > detailed? > "Copy" operation already have a meaning when manipulating objects, > "Template" is obviously already taken too, > > So maybe something like "code-copy" or "type-copy" or something like that > would fit best. > > My main question while reading this proposal: > What happen if the original type have a hidden implementation? > That is: > > > class A { > class Impl; > Impl* pimpl; > public: > A();. > Impl* fork(); > }; > > class B : using C {}; > > Assuming A's functions are defined in another translation unit which is > already compiled (for example a shared library file): > > 1. Is this allowed by your proposal? > 2. If yes, what is the type of B::Impl? A typedef of A::Impl? > 3. Do you propose that nested types be implicitly type-copied too? > > Then: > > 4. I'm also concerned by symbol export/import in these cases. Even if not > defined by the standard, if the feature have strong limitations when > importing/exporting symbols, it might become a no-go proposal. > > > 5. What about class specifiers like alignof/alignas? Are they maintained? > How would one remove them? > > 6. Would there be a way to remove types and typedefs from the original > type? > Just wondering, not a feature request. > > Jo=C3=ABl Lamotte. > > > > > > > > Sent from mobile. > > On Dec 20, 2016 7:02 PM, "Eugenio Bargiacchi" wrote= : > >> I'm not sure you can `static_cast` between pointers of unrelated classes >> (I think not actually). `reinterpret_cast` is also very limited in what = it >> can do in this case: I'm not 100% sure on the details, but in general I >> think it is allowed only when the two classes are `standard_layout` (whi= ch >> has a bunch of restrictions). >> >> In any case, please note that `reinterpret_cast` is used as an example, >> and it would still keep all already existing rules with no modifications= , >> as this proposal does not even try to go there. How an user would like t= o >> use the feature and define additional methods is his/her concern. In ter= ms >> of the proposal, all cpp features work as if the user had implemented th= e >> new class by hand, so no new rules have to be introduced. >> >> On Tue, Dec 20, 2016 at 6:49 PM, D. B. wrote: >> >>> A quick comment on one thing that stuck out to me while skimming. For >>> now I'll leave the real review to those with more time/experience. >>> >>> Is reinterpret_cast really the correct tool for this? It seems to me >>> like static_cast would be more appropriate. >>> >>> Think int vs enum class. The types are not implicitly substitutable but >>> are *really* the same, or at least sub/supersets... sound familiar? So >>> an explicit static_cast should be safe and preferable, by my understand= ing. >>> >>> To me reinterpret_cast signals (screams) 'I probably shouldn't be doing >>> this, but there's no other way, and I promise this pointer/reference wa= s >>> originally (compatible with) what I'm saying it is... honest'. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "ISO C++ Standard - Future Proposals" group. >>> To unsubscribe from this topic, visit https://groups.google.com/a/is >>> ocpp.org/d/topic/std-proposals/gkJUVnL-Fmg/unsubscribe. >>> To unsubscribe from this group and all its topics, 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/is >>> ocpp.org/d/msgid/std-proposals/CACGiwhHGNADMd0orere%3DYZ2_y7 >>> UB8Y0MPU5p25d1fE8i2WKrpA%40mail.gmail.com >>> >>> . >>> >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> 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/is >> ocpp.org/d/msgid/std-proposals/CAHfn%3D%2Bsw7zmU8iz7Ysc3e7cp >> vf3GdrZW32x0pGggvMP%3DFOY8xQ%40mail.gmail.com >> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit https://groups.google.com/a/is > ocpp.org/d/topic/std-proposals/gkJUVnL-Fmg/unsubscribe. > To unsubscribe from this group and all its topics, 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/is > ocpp.org/d/msgid/std-proposals/CAOU91OPx4SQ_dLiHnpmXXqj69n7t > W%3DOwOb60dXksnWWt8UjViA%40mail.gmail.com > > . > --=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/CAHfn%3D%2BstH4eSm5FxQXT%2Barev9QDnni0P8SSwGRh8a= XLrhmQx7w%40mail.gmail.com. --001a1143b094cc480405442a786b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bengt, I understan= d it may get a bit complicated. Replacements are actually a feature that I = proposed just to get it considered. I believe the feature should allow to a= dd new methods/features to a class; substituting/deleting existing function= ality is more complicated but it could have its use cases and would allow t= o make better use of existing class implementations, so that's why I ad= ded it for considerations.

About the part on interdependent cl= asses I have written that the classes should be "defined" as copi= es of their aliased equivalent. Not sure if the compiler can handle it in o= ne pass, or if there is a better way to state that requirement.

I believe that making strong typedefs in general is important, and not on= ly for primitive types. Sure making them on primitive types only would stil= l be an improvement, but there are many compelling use-cases for also makin= g strong typedefs of classes, for example in scientific fields.

I have added in my examples copy constructors and the like since they are= considered heavily in the already existing proposals, and they state that = requirements were gathered after extensive discussions with many potential = users. It's definitely not a requirement to add them, I just wanted to = show how it could be done since it could be needed.

Jo<= span class=3D"m_-6092875754422023223gmail-_Tgc">=C3=ABl, about copy I feel = the same way. I'll try to work out a nicer terminology.

About in= ternal classes, this is a very good question. Actually I realized yesterday= that another thing which could be hard to define correctly would be how to= treat `friend` declarations. A relatively simple solution would be that al= l names that depend on the original name are copied, while those that don&#= 39;t are not ported over (for example friend method declarations/definition= s).

So= in your example A::Impl would be copied into B::Impl. However, in this exa= mple:

void bar() {}

struct A {
=C2=A0=C2=A0=C2=A0 friend int foo(A) { return 0; }
=
=C2=A0=C2=A0=C2=A0 f= riend void bar();
};

struct B : using A {};

Nothing would be copied, since the= functions `foo` and `bar` do not depend directly on the original type. If = needed, a different `int foo(B)` can be separately implemented by the copie= r. It's not exactly intuitive, but I believe it would be better, otherw= ise copying everything defined "internally" could lead to recursi= ve copying of many things which one would not expect copied.

=
About symbols, = personally I think they should work as if the user had written the new clas= s by hand, if possible. This should keep the rules relatively simple, as a = user can always create a new copy of a class by hand (one cannot do inherit= ance by hand, for example, as the language gives guarantees about it not ac= hievable by writing a new class from scratch).

I would say alignof/as would= be kept. The same for existing typedefs. The idea here is to offer a certa= in amount of customizations of classes that are copied, but not too much - = otherwise it would be best for the user to just create the new type by hand= .. The line must be drawn somewhere, and I'd prefer the feature to be si= mple rather than having to define how to take apart an existing type. Ideal= ly the feature would be more constructive than destructive, as in first def= ine types, and each copy adds stuff, rather than start with a big type and = remove things from it. Having the possibility to remove things however give= s space to make better use of existing classes, and that's why I includ= ed it.

Best,
Eugenio

<= div class=3D"gmail_quote">On Wed, Dec 21, 2016 at 10:03 AM, Klaim - Jo=C3= =ABl Lamotte <mjklaim@gmail.com> wrote:
Hi,
This is an interesting= proposal.
May I suggest you change your "copy&= quot; word usage for something else or more detailed?
"Copy" operation already have a meaning when manipulating objec= ts,
"Template" is obviously already taken = too,

So maybe something = like "code-copy" or "type-copy" or something like that = would fit best.

My main = question while reading this proposal:
What happen if= the original type have a hidden implementation?
Tha= t is:


=C2=A0 =C2=A0 class A {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 class Impl;=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Impl* pimpl;=C2=A0
=C2=A0 =C2=A0 public:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A();. =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Impl* fork(= );
=C2=A0 =C2=A0 =C2=A0};
=C2= =A0
=C2=A0 =C2=A0 =C2=A0class B : using C {};
<= div dir=3D"auto">
Assuming A's functions are= defined in another translation unit which is already compiled (for example= a shared library file):

1. Is this allowed by your proposal?
2. If yes, wha= t is the type of B::Impl? A typedef of A::Impl?=C2=A0
3. Do you propose that nested types be implicitly type-copied too?
<= div dir=3D"auto">
Then:
<= br>
4. I'm also concerned by symbol export/impor= t in these cases. Even if not defined by the standard, if the feature have = strong limitations when importing/exporting symbols, it might become a no-g= o proposal.


5. What about class specifiers like alignof/alignas? Are th= ey maintained? How would one remove them?

=
6. Would there be a way to remove types and typedefs from= the original type?
Just wondering, not a feature re= quest.

Jo=C3=ABl Lamotte= ..

=C2=A0
=C2=A0




Sent from mobile.

On De= c 20, 2016 7:02 PM, "Eugenio Bargiacchi" <svalorzen@gmail.com> wrote:
I'm not sure yo= u can `static_cast` between pointers of unrelated classes (I think not actu= ally). `reinterpret_cast` is also very limited in what it can do in this ca= se: I'm not 100% sure on the details, but in general I think it is allo= wed only when the two classes are `standard_layout` (which has a bunch of r= estrictions).

In any case, please note that `reinterpret_cast`= is used as an example, and it would still keep all already existing rules = with no modifications, as this proposal does not even try to go there. How = an user would like to use the feature and define additional methods is his/= her concern. In terms of the proposal, all cpp features work as if the user= had implemented the new class by hand, so no new rules have to be introduc= ed.

On T= ue, Dec 20, 2016 at 6:49 PM, D. B. <db0451@gmail.com> wrote:<= br>
A quick comment on = one thing that stuck out to me while skimming. For now I'll leave the r= eal review to those with more time/experience.

Is reinterpret_cast really the correct tool for this? It seems to me like static_cast would be more appropriate.

Think int vs enum class. The types are not implicitly substitutable but are <= i>really the same, or at least sub/supersets... sound familiar? So an e= xplicit static_cast should be safe and preferable, by my understanding.
=
To me reinterpret_cast signals (screams) 'I probably shouldn'= t be doing this, but there's no other way, and I promise this pointer/r= eference was originally (compatible with) what I'm saying it is... hone= st'.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/g= kJUVnL-Fmg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/st= d-proposals/CACGiwhHGNADMd0orere%3DYZ2_y7UB8Y0MPU5p25d1fE8i2WKrpA= %40mail.gmail.com.

--
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-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/msgi= d/std-proposals/CAHfn%3D%2Bsw7zmU8iz7Ysc3e7cpvf3GdrZW32x0pGggvMP%= 3DFOY8xQ%40mail.gmail.com.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/g= kJUVnL-Fmg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/st= d-proposals/CAOU91OPx4SQ_dLiHnpmXXqj69n7tW%3DOwOb60dXksnWWt8UjViA= %40mail.gmail.com.

--
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/CAHfn%3D%2B= stH4eSm5FxQXT%2Barev9QDnni0P8SSwGRh8aXLrhmQx7w%40mail.gmail.com.
--001a1143b094cc480405442a786b-- .