220 30156 article Path: news.gmane.org!.POSTED!not-for-mail From: Eugenio Bargiacchi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A strong typedef syntax idea Date: Mon, 2 Jan 2017 19:21:53 +0100 Lines: 1632 Approved: news@gmane.org Message-ID: References: <9574d1c1-b3ff-b9ae-ceee-908a2b983278@wanadoo.fr> <9adc5a02-3209-bf63-a684-fb0272da56e0@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f403045dd9604a4623054520a069 X-Trace: blaine.gmane.org 1483381323 29806 195.159.176.226 (2 Jan 2017 18:22:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jan 2017 18:22:03 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCWJHLVBTMARBQVUVLBQKGQEDPYG2NQ@isocpp.org Mon Jan 02 19:21:56 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cO7F1-0006O0-MW for gclcip-std-proposals@m.gmane.org; Mon, 02 Jan 2017 19:21:52 +0100 Original-Received: by mail-yw0-f200.google.com with SMTP id t11sf371193794ywe.3 for ; Mon, 02 Jan 2017 10:21:55 -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=BD9RBLJR8Y7W60xRxdw6EE0UVUnpzUNr1DcDoOhNbnE=; b=sfxaK/hg09yaV6CFxi3/y82o2qHpszfThqB1PnJIwFbQmS2NGigi0QGhSoMpOZgiRF 9KkIAR2CxLZ98dWgj43sKOr1O6Ukzh8xsBvx/rxTWDifg9s9uDPvjo0+I8ghAdd9mPbD 0u7U1aQfSeB65/oe0iuqoZHKHRggSBhMWUq20nu5RaazKeTOW5UIeNTppqc+xlVrcLFL NJ2qaZ1VOPKjWkIbgO03ILSYkty8no0/hf0Gbl+l/HfaT9VtwbQxGghdlS1zOlFsTxGj YScMEosvgLdFRtBdczgE7Q4NP8HnXWUpXFOFVdMr33RaKISNA8NAj86Lyy/muL71nSI1 4lig== 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=BD9RBLJR8Y7W60xRxdw6EE0UVUnpzUNr1DcDoOhNbnE=; b=r1QR/TptkE8Ms0BWQnsx+b8Fq8sklol2yFxfxQ3b+YF7mXZWPa1KKbkYQgzrMyynu3 PJpkzQP+p0abfcFl1z/p7Wbmh9zJoNNsP1WYMA9FbtlA0QrZ91gDSlGsZpMEdMiOWe61 kUsKt3X+7tQMpznMeUOwsbMvwubXfTNlM1SYYgBqlfMo3THqTMXft5KJMoJsb2/6aD19 9TN4jWUwL3xKCfFZd+FSKwhpQw2obwILNpRgtZuuvrA1GtF3efrONj5Z2R8l1EUrltKy 2ezSTOHG7x0zN8DuqlQSj5uP8gyWPpku+KKEeUZAQ8fO1HZo1pEvVQAHjzGZCIcuMB3a 8B0Q== X-Gm-Message-State: AIkVDXLvny3ogHNE3tOS4Bm9GMBJQYHjM4wTaOZQu2k6aQnhOUppuahTiUlo4nlR3oAw5g== X-Received: by 10.13.202.83 with SMTP id m80mr16292937ywd.29.1483381315505; Mon, 02 Jan 2017 10:21:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.137 with SMTP id z9ls43482299otd.28.gmail; Mon, 02 Jan 2017 10:21:54 -0800 (PST) X-Received: by 10.176.84.8 with SMTP id n8mr43887626uaa.29.1483381314632; Mon, 02 Jan 2017 10:21:54 -0800 (PST) Original-Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com. [2607:f8b0:400c:c08::235]) by mx.google.com with ESMTPS id y26si12887697uae.155.2017.01.02.10.21.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 10:21:54 -0800 (PST) Received-SPF: pass (google.com: domain of svalorzen@gmail.com designates 2607:f8b0:400c:c08::235 as permitted sender) client-ip=2607:f8b0:400c:c08::235; Original-Received: by mail-ua0-x235.google.com with SMTP id 34so266570265uac.1 for ; Mon, 02 Jan 2017 10:21:54 -0800 (PST) X-Received: by 10.176.85.24 with SMTP id t24mr46997654uaa.21.1483381314043; Mon, 02 Jan 2017 10:21:54 -0800 (PST) Original-Received: by 10.31.227.133 with HTTP; Mon, 2 Jan 2017 10:21:53 -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:c08::235 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:30156 Archived-At: --f403045dd9604a4623054520a069 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Vicente, > As in, the compiler knows that the first piece of the class will be the > same as the original, and every new member is added at the end. > > So if we argree that internal conversions are needed from/to the > underlying type, the new strong type couldn't add any new non-static data > member :) > I'm not sure I agree fully, but in any case the ability to add new non-static data members is not something I feel strongly about at the moment. It's something that can be added in a future proposal if there should arise a need. =3D) Maybe I'll just remove this from the proposal for the moment. > Yes, of course. What I mean is, you have created a class which can only > create exact copies of it. If you need additional changes, it will probab= ly > be easier to strong-type the original again and create new trampolines fr= om > that. This is what I mean by non-extendable. > > Why? I don't understand. > It may be that I just have a different idea in my head on how p0109 would work in practice. I just have a feeling that those strong typedefs could be hard to work with, but I may just have misunderstood some parts. > I start to see what you mean. But still, if one could add them, the copy > would still "contain" an equivalent of the original class at its beginnin= g. > It wouldn't be guaranteed reinterpret_cast-able, but the fields would be > there anyway. The original representation is there - so to me it could > still be considered a strong-typedef (stretching a bit the definition > maybe). > > Remember that you need conversions from both sides to implement the > trampolines. > Well, in inheritance child classes can be converted to their parents automatically (even if they don't define a constructor that initializes any new data they might have). If that can be done I don't see why this would be impossible for a copied class + a new non-static data member to do the same thing. > Well, if only the public interface is available, than adding new methods > to it is pretty much equivalent with creating non-member functions (since > those work with public interface). Then you might as well remove the > ability to add new member functions, since non-members will do just fine > and there's no need to have them as members. > > People like member functions also ;-) > Eh, true. But every feature must be justified by a use case! ;D (joking) > template > class ConvertBack : using C { > > public: > Whoops! > // Strong typedef of double with +,- convertible to double > struct MyDouble : using ConvertBack>>> {} > > This example is already more complete. Thanks. > > -------------------------------------------- > > ConvertBack will convert to Minus>> :( > > Maybe the conversion should be part of Wrap or wrap should provide a > underlying function as I have in my library. > > operator+ returns Plus> but we want MyInt or MyDouble :( > > See below how you could return the Final class. > Not exactly! I'll try to analyze MyDouble to explain how it works. Wrap I believe we both understand it. So now let's consider Plus>. template struct Plus : using C { // changed to struct to avoid public Plus operator+(Plus other) { return Plus{t_ + other.t_}; } }; So it copies the templated class, and adds the operator+ to it. So the class becomes the equivalent of: struct Plus { // Equivalent of Plus> using base_type =3D double; Plus(const Plus & other) : t_(other.t_) {} explicit Plus(double t) : t_(t) {} Plus operator+(Plus other) { return Plus{t_ + other.t_}; } private: double t_; }; See? Now any mention of Wrap has disappeared, since we copied that. Wrap, the original class, has been replaced by Plus (since we are copying). After the minus, the same thing would happen: struct Minus { // Equivalent of struct Minus>> using base_type =3D double; Minus(const Minus & other) : t_(other.t_) {} explicit Minus(double t) : t_(t) {} Minus operator+(Minus other) { return Minus{t_ + other.t_}; } Minus operator-(Minus other) { return Minus{t_ - other.t_}; } private: double t_; }; And finally, the last step: struct ConvertBack { // Equivalent of struct ConvertBack>>> using base_type =3D double; ConvertBack(const ConvertBack & other) : t_(other.t_) {} explicit ConvertBack(double t) : t_(t) {} // From Plus originally ConvertBack operator+(ConvertBack other) { return ConvertBack{t_ + other.t_}; } // From Minus originally ConvertBack operator-(ConvertBack other) { return ConvertBack{t_ - other.t_}; } // From ConvertBack, unchanged, but using the typedef (base_type) made initially in Wrap operator base_type() { return t_; } private: double t_; }; I hope this makes more sense to you. template > class AFct : using C { > public: > friend Final aFct(Final other) { return Final{aFct(other.t_)}; } > }; This could be a way, yes. One option is to simply define a constructor in B which takes A. Otherwise, > it would be the same case when you create a class with a member which the > constructor does not initialize. Otherwise one exception could be made fo= r > constructors so that they can be redefined in the new class. This probabl= y > makes sense and it shoudn't be possible to break something (unless one > creates a constructor which does not initialize some fields which are > assumed initialized by the original class.. but then I believe it's a > reasonable risk). > > I suggest you try it and see how it works. Let me know if it is reasonabl= e. > I'll try to work on this a bit then. Well, friend functions are not members, so if you allow copying them, you > are allowing copying arbitrary non-member functions (which I approve of). > The only problem with this is that it is a big change - on top of this > proposal. Just that. > > Not exactly. The compiler can copy the friend functions because it is > aware of these functions and so it could copy them. > This seems reasonable. However, you still have to specify non-member functions manually, since the > compiler cannot assume you want them all. > > I believe you could let the user copy non-member non-friend function by > itself. Yes. However, can you do this process on random non-member functions to change their parameters to other types? If not, why not? Are you constrained in doing this only in copied class and with functions taking/returning the original class, maybe? Why? I'm not sure what the answers should be. Well, it is not really transitivity. As in, the C to A transition does not > need an implicit transition from B. The user is explicitly creating the > conversion operator. The data in C exists, so it can be copied directly. > Maybe you mean transitivity in the sense that the compiler needs to > remember that C is a copy of B in order for it to know that it is also a > copy of A. In that case I agree. > > Yes this is the case. You are requesting the compiler to do the conversio= n > transitively. > Makes sense. Then forget the idea =3D) Best, Eugenio On Mon, Jan 2, 2017 at 6:48 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote: > Le 02/01/2017 =C3=A0 13:31, Eugenio Bargiacchi a =C3=A9crit : > > Dear Vicente, > > Eugenio, I believe the use cases we have both in mind are quite different= , >> and so we don't reach to understand one to each other. > > > It seems so. I am available to try other forms of communications if you > want (chat, voice call) if you want. I'm sorry I'm not being as clear as = I > want. > > No problem. It is my fault also. > > > I have a question. Does you copy class proposal needs to have the >> definition of the copied class available? >> If yes, I don't think this could be acceptable. >> If the declaration is enough, the copied functions would need at least a= n >> internal conversion to/from the underlying type, isn't it? >> > > My proposal does not need the definition. Yes, I suppose an internal > conversion would be needed. The internal conversion would probably work > similarly to how inheritance works, even if adding non-static members was > allowed. As in, the compiler knows that the first piece of the class will > be the same as the original, and every new member is added at the end. > > So if we argree that internal conversions are needed from/to the > underlying type, the new strong type couldn't add any new non-static data > member :) > > B b; >> b.A::bar(5); >> >> Agreed. And the language let me do that even if you find it could be bad >> practice. I don't see why your copy approach wouldn't let me do that. >> > > In my approach the old function is impossible to hide, so I think that th= e > two cases are different. > >> If in all these cases your answer is "the program will fail to compile, >> just copy the class by hand" then I think the feature would be severely >> limited in what it could actually do. >> >> You are probably right, and the copy should copy every thing and give >> access to everything internally. I need some concrete examples to >> understand what this possibility will solve. >> > > Well, for example, a library that wanted to create strong typedefs of > primitive types via wrappers and only expose certain operations, without > getters/setters ;) I've added some code later to show you how a possible > implementation using this proposal. > >> If I understand correctly, you want to hide the original completely, and >> just be offered an easy way to bring back some of its interface (via >> trampolines) to its "wrapper", which would be the strong typedef. >> >> I wouldn't say hiding, just don't looking inside the underlying type. I >> want to provide access to it (when needed) but only as a whole. >> >> Possibly adding more public methods only using the public interface, >> which could be done just the same with non-member methods. The end resul= t >> is a class that cannot be extended in any meaningful way using any of th= e >> normal C++ facilities, since every juicy bit is hidden. >> >> Why it is unusable? The class provide access to everything you want. >> > > Classes don't always come with getters and setters for every private > field. Especially if the interface they provide is a high level one. It > happens often in low-level code that you want to interact with the > underlying bits in very specific ways, but you don't necessarily want to > give that kind of access to users. So creating a strong typedef of such a > class while adding a new mode of operation would be impossible, as the co= py > won't have access to the underlying implementation. > > Another could be when you have to types that you know contain the same > (private) data, but should expose different public interfaces. Then you > could first create the class containing the data, and copy it two times, > each time exposing a different interface (which would need access to the > private data). Once again, I unfortunately don't have a practical use cas= e > at the moment. I just think it could be useful. > > Still the code below is a good use-case I think, since it would be needed > to provide strong typedefs of primitive types. > >> Applying strong-typing again to a strong-typed class would be useless as >> access to internals would be the same, >> >> You can strong-type again. I don't see the trouble. E.g; you can have a >> energy strong-type and have kinetic_energy, potential_energy and >> heat_energy strong-type of energy. >> Typing and representation are two different things. Strong types are jus= t >> that. Share a representation and have different types. >> > > Yes, of course. What I mean is, you have created a class which can only > create exact copies of it. If you need additional changes, it will probab= ly > be easier to strong-type the original again and create new trampolines fr= om > that. This is what I mean by non-extendable. > > Why? I don't understand. > > aside from possibly adding more data (if needed) in the public attributes= , >> since only those are editable. This would also prevent encapsulation of = new >> data. If not, it would just mean that the feature wouldn't be used in a >> composable way. >> >> I believe now that strong-type shouldn't add any new non-static data >> member > > > I start to see what you mean. But still, if one could add them, the copy > would still "contain" an equivalent of the original class at its beginnin= g. > It wouldn't be guaranteed reinterpret_cast-able, but the fields would be > there anyway. The original representation is there - so to me it could > still be considered a strong-typedef (stretching a bit the definition > maybe). > > Remember that you need conversions from both sides to implement the > trampolines. > > > Is there any other reason why you don't like the idea? > > No, but it is enough. > > A feature that creates a non-extendable object is like a dead-end. >> >> I must agree with your last sentence, but I don't think the strong-types >> I'm suggesting are non-extendable? >> > > Well, if only the public interface is available, than adding new methods > to it is pretty much equivalent with creating non-member functions (since > those work with public interface). Then you might as well remove the > ability to add new member functions, since non-members will do just fine > and there's no need to have them as members. > > People like member functions also ;-) > > > But wrappers can be made in a separate library. Why should they be >> included in the proposal? As long as the proposal allows them, a library >> only needs to be made once (and if not needed by someone, not used). >> >> We need some probe of concept applied to concrete examples we want to >> solve. I believe a strong type feature must solve the builtin type case.= If >> your proposal is not a strong type proposal, then forget my comments. >> > > This is how I would practically solve the primitive types problem using m= y > proposal: > > ------------------------------------------ > > // library.hpp > > template > class Wrap { > public: > using base_type =3D T; > > Wrap(const Wrap & other) : t_(other.t_) {} > explicit Wrap(T t) : t_(t) {} > > private: > T t_; > }; > > template > class ConvertBack : using C { > > public: > > operator base_type() { return t_; } > }; > > template > class Plus : using C { > > public: > > Plus operator+(Plus other) { return Plus{t_ + other.t_}; } > }; > > template > class Minus : using C { > Minus operator-(Minus other) { return Minus{t_ - other.t_}; } > }; > > template > class Prod : using C { > Prod operator+(Prod other) { return Prod{t_ * other.t_}; } > }; > > template > class Div : using C { > Div operator/(Div other) { return Div{t_ / other.t_}; } > }; > > template > using Arithmetic =3D Div>>>>; > > // .... and so on > > // usercode.cpp > > #include "library.hpp" > > // Strong typedef of int with +,-,/,* > struct MyInt : using Arithmetic {} > > // Strong typedef of double with +,- convertible to double > struct MyDouble : using ConvertBack>>> {} > > This example is already more complete. Thanks. > > -------------------------------------------- > > ConvertBack will convert to Minus>> :( > > Maybe the conversion should be part of Wrap or wrap should provide a > underlying function as I have in my library. > > operator+ returns Plus> but we want MyInt or MyDouble :( > > See below how you could return the Final class. > > > If there's something missing you'd like to see how I'd do, let me know. O= f > course verbosity depends on granularity. If all operations need to be > manually selected you'll have lots of classes. If the granularity require= d > is less each class could add more operators at once. > > Note that you need access to privates to be able to do this, so this coul= d > be an use-case for that. > > I like the idea and yes it needs access to the private data. However if w= e > want to be able to provide the conversion to the underlying type, it seem= s > that the underlying data is no more private anymore and should at least = be > read. To be fair, I have never created strong types for classes that are > not builtin types, or that are not copied completely. If the function you > want to add modifies only part of the underlying type then either the > underlying type provides already this possibility, or the new type would > need access to the private part as you propose. > > I would need to see how I could adapt my Opaque library with this languag= e > feature and see if it could be more simple. I will try with private and > without access. > > > A problem that is not tackled in this code and that we are also discussin= g > is what to do with non-member functions (that could possibly take base_ty= pe > as input). That depends on how non-member functions will be handled in th= e > proposals. If they can be handled I would actually be happier. > > template > class AFct : using C { > public: > friend Final aFct(Final other) { return Final{aFct(other.t_)}; } > }; > > > Forcing the user to inherit to add more data adds inheritance, which mean= s >> that types are now implicitly convertible (to at least a common base). I >> don't think this is desirable. I think strong typing should work on its = own. >> >> How then you will be able to construct a B from a A if B adds more >> non-static data members? >> > > One option is to simply define a constructor in B which takes A. > Otherwise, it would be the same case when you create a class with a membe= r > which the constructor does not initialize. Otherwise one exception could = be > made for constructors so that they can be redefined in the new class. Thi= s > probably makes sense and it shoudn't be possible to break something (unle= ss > one creates a constructor which does not initialize some fields which are > assumed initialized by the original class.. but then I believe it's a > reasonable risk). > > I suggest you try it and see how it works. Let me know if it is reasonabl= e. > > > As you want to inherit all the member functions from the underlying class= , >> it has a sens to concentrate on member functions. I don't understand why >> friend functions could not follow the same schema. >> > > Well, friend functions are not members, so if you allow copying them, you > are allowing copying arbitrary non-member functions (which I approve of). > The only problem with this is that it is a big change - on top of this > proposal. Just that. > > Not exactly. The compiler can copy the friend functions because it is > aware of these functions and so it could copy them. > > > void foo(int); >> >> void foo(double) : using foo(int); >> >> to use an analogous syntax to the one in my proposal. Not sure if this i= s >> clearer, let me know. >> >> I believe I understand you now but I don't see how this could help. >> > > Well, this would be the way to create the "trampolines" for non-member > functions. When you copy a class, you specify just once from which class > you are copying. The compiler can then apply the change to all member > functions automatically. > > However, you still have to specify non-member functions manually, since > the compiler cannot assume you want them all. > > I believe you could let the user copy non-member non-friend function by > itself. > > > and also to A (since C is a type-copy of a type-copy). >> >> The first Opaque proposal contained a implicit subsumption relation that >> allowed that. I'm all for, but I believe the committee doesn't like >> transitivity in conversions. >> > > Well, it is not really transitivity. As in, the C to A transition does no= t > need an implicit transition from B. The user is explicitly creating the > conversion operator. The data in C exists, so it can be copied directly. > Maybe you mean transitivity in the sense that the compiler needs to > remember that C is a copy of B in order for it to know that it is also a > copy of A. In that case I agree. > > Yes this is the case. You are requesting the compiler to do the conversio= n > transitively. > > > Vicente > > -- > 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/ > isocpp.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/ > isocpp.org/d/msgid/std-proposals/edb42928-1e58-ee22- > 79ce-0fedd07247f1%40wanadoo.fr > > . > --=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%2BsJCyDr4sVhXK-9c9cn0JOdaWt7Fr1ejiCBVT7= Ab%3DYbew%40mail.gmail.com. --f403045dd9604a4623054520a069 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Vicente,
As in, the compiler knows that the first piece of the class will be the same as the original, and every new member is added at the end.
 So if we argree that internal conversions are needed from/to the underlying type, the new strong type couldn't add any new non-stati= c data member :)
I'm not sure I agree fully, but in any case the ability to = add new non-static data members is not something I feel strongly about at t= he moment. It's something that can be added in a future proposal if the= re should arise a need. =3D)

Maybe I'll just remove t= his from the proposal for the moment.
Yes, of course. What I mean is, you have crea= ted a class which can only create exact copies of it. If you need additional changes, it will probably be easier to strong-type the original again and create new trampolines from that. This is what I mean by non-extendable.
 Why? I don't understand.
=C2=A0
It may be that I just have a differen= t idea in my head on how p0109 would work in pract= ice. I just have a feeling that those strong typedefs could be hard to work= with, but I may just have misunderstood some parts.
<= div>I start to see what you mean. But still, if one could add them, the copy would still "contain" an equival= ent of the original class at its beginning. It wouldn't be guaranteed reinterpret_cast-able, but the fields would be there anyway. The original representation is there - so to me it could still be considered a strong-typedef (stretching a bit the definition maybe).
Remember that you need conversions from both sides to implement the trampolines.

<= /div>
Well, in inheritance child classes can be converted to their pare= nts automatically (even if they don't define a constructor that initial= izes any new data they might have). If that can be done I don't see why= this would be impossible for a copied class + a new non-static data member= to do the same thing.
<= div>
Well, if only the public interface is available, than adding new methods to it is pretty much equivalent with creating non-member functions (since those work with public interface). Then you might as well remove the ability to add new member functions, since non-members will do just fine and there's no need to have them as members.
People like member functions also ;-)

Eh, true. But every feature must be just= ified by a use case! ;D (joking)
template <typename C>
class ConvertBack : using C {
 public:

= =C2=A0Whoops!
=
// Strong typedef of double with +,- conver= tible to double
struct MyDouble : using ConvertBack<Minus<Plus<Wrap<double>>&g= t;> {}

 This example is already more complete. Thanks.
--------------------------------------------
ConvertBack will convert to Minus<Plus<Wrap<double>>> :(

Maybe the conversion should be part of Wrap or wrap should provide a underlying function as I have in my library.

operator+ returns Plus<Wrap<double>> but we want MyInt or MyDouble :(

See below how you could return the Final class.
Not exactly!

I= 9;ll try to analyze MyDouble to explain how it works.

Wra= p<double> I believe we both understand it. So now let's consider = Plus<Wrap<double>>.

template <typename C>
struc= t Plus : using C { // changed to struct to avoid public
=C2=A0=C2=A0=C2= =A0 Plus operator+(Plus other) { return Plus{t_ + other.t_}; }
};
So it copies the templated class, and adds the operator+ to it.= So the class becomes the equivalent of:

struct Plus { //= Equivalent of Plus<Wrap<double>>
= =C2=A0=C2=A0=C2=A0 using base_type =3D double;

=C2=A0=C2=A0=C2=A0 Plus(const Plus & other) : t_(other.t_= ) {}
=C2=A0=C2=A0=C2=A0 explicit Plus(double t) : t_(t) {}

= =C2=A0=C2=A0=C2=A0 Plus operator+(Plus other) { return Plus{t_ + oth= er.t_}; }=C2=A0=C2=A0=C2=A0
private:
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 double t_;
};

See?= Now any mention of Wrap has disappeared, since we copied that. Wrap<dou= ble>, the original class, has been replaced by Plus (since we are copyin= g). After the minus, the same thing would happen:

struct Minus = { // Equivalent of struct Minus<Plus<Wrap<double>>>
=C2=A0=C2=A0=C2=A0 using base_type =3D double;

=C2=A0=C2=A0=C2=A0 Minus(const Minus & other) : t_(other.= t_) {}
=C2=A0=C2=A0=C2=A0 explicit Minus(double t) : t_(t) {}
=C2=A0=C2=A0=C2=A0 Minus operator+(Minus other) { return Minus{t_ += other.t_}; }
=C2=A0=C2=A0=C2=A0 Minus operator= -(Minus other) { return Minus{t_ - other.t_}; }=C2=A0
private:
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 double t_;
};

And finally, the last step:

struct ConvertBack { = // Equivalent of struct ConvertBack<Minus<Plus<Wrap<double>&= gt;>>
=C2=A0=C2=A0=C2=A0 using base_type = =3D double;

=C2=A0=C2=A0=C2=A0 ConvertBac= k(const ConvertBack & other) : t_(other= ..t_) {}
=C2=A0=C2=A0=C2=A0 explicit C= onvertBack(double t) : t_(t) {}

=C2=A0=C2=A0=C2=A0 // From Plus originally
=C2= =A0=C2=A0=C2=A0 ConvertBack operator+(ConvertBack other) { return ConvertBa= ck{t_ + other.t_}; }
=C2=A0=C2=A0=C2=A0 // From Minus origina= lly
=C2=A0=C2=A0=C2=A0 ConvertBack operator-(Co= nvertBack other) { return ConvertBack{t_ - other.t_}; }
= =C2=A0=C2=A0=C2=A0 // From ConvertBack, unchanged, but using the typedef (b= ase_type) made initially in Wrap<double>
=C2=A0=C2=A0=C2=A0 operator base_type() { return t_; }
private:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = double t_;
};

I hope this makes more sense to yo= u.

template <ty= pename Final, typename C>
class AFct : using C {
public:
=C2=A0=C2=A0=C2=A0 friend Final aFct(Final other) { return Final{aFct(o= ther.t_)}; }
};

This could be a way, yes.

One option= is to simply define a constructor in B which takes A. Otherwise, it would be the same case when you create a class with a member which the constructor does not initialize. Otherwise one exception could be made for constructors so that they can be redefined in the new class. This probably makes sense and it shoudn't be possible to break something (unless one creates a constructor which does not initialize some fields which are assumed initialized by the original class.. but then I believe it's a reasonable risk).
 I suggest you try it and see how it works. Let me know if it is reasonable.

I'll try to work on this a bit then.

Well, friend fun= ctions are not members, so if you allow copying them, you are allowing copying arbitrary non-member functions (which I approve of). The only problem with this is that it is a big change - on top of this proposal. Just that.
 Not exactly. The compiler can copy the friend functions because it is aware of these functions and so it could copy them.

This seems reasonable.<= br>
However, you still have to specify non-member functions manually, since the compiler cannot assume you want them all.
 I believe you could let the user copy non-member non-friend function by itself.

Yes. However, can you do thi= s process on random non-member functions to change their parameters to othe= r types? If not, why not? Are you constrained in doing this only in copied = class and with functions taking/returning the original class, maybe? Why?
I'm not sure what the answers should be.

Well, it is= not really transitivity. As in, the C to A transition does not need an implicit transition from B. The user is explicitly creating the conversion operator. The data in C exists, so it can be copied directly. Maybe you mean transitivity in the sense that the compiler needs to remember that C is a copy of B in order for it to know that it is also a copy of A. In that case I agree.
 Yes this is the case. You are requesting the compiler to do the conversion transitively.

Makes sens= e. Then forget the idea =3D)

Best,
Eugenio<= br>

On Mon, Jan 2, 2017 at 6:48 PM, Vi= cente J. Botet Escriba <vicente.botet@wanadoo.fr> wro= te:
=20 =20 =20
Le 02/01/2017 =C3= =A0 13:31, Eugenio Bargiacchi a =C3=A9crit=C2=A0:
Dear Vicente,

Eugenio, I believe the use cases we have both in mind are quite different, and so we don't reach to understand one to each other.

It seems so. I am available to try other forms of communications if you want (chat, voice call) if you want. I'= m sorry I'm not being as clear as I want.
 No problem. It is my fault also.

I have a questi= on. Does you copy class proposal needs to have the definition of the copied class available?
If yes, I don't think this could be acceptable.
If the declaration is enough, the copied functions would need at least an internal conversion to/from the underlying type, isn't it?

My proposal does not need the definition. Yes, I suppose an internal conversion would be needed. The internal conversion would probably work similarly to how inheritance works, even if adding non-static members was allowed. As in, the compiler knows that the first piece of the class will be the same as the original, and every new member is added at the end.
 So if we argree that internal conversions are needed from/to the underlying type, the new strong type couldn't add any new non-stati= c data member :)
B b;
b.A::bar(5);

 Agreed. And the language let me do that even if you find it could be bad practice. I don't see why your copy approach wouldn't let me do that.

In my approach the old function is impossible to hide, so I think that the two cases are different.
If in all these cases your answer is "t= he program will fail to compile, just copy the class by hand" then I think the feature would be severely limited in what it could actually do.
 You are probably right, and the copy should copy every thing and give access to everything internally. I need some concrete examples to understand what this possibility will solve.

Well, for example, a library that wanted to create strong typedefs of primitive types via wrappers and only expose certain operations, without getters/setters ;) I've added some code later to show you how a possible implementation using this proposal.
If I understand correctly, you want to hide the original completely, and just be offered an easy way to bring back some of its interface (via trampolines) to its "wrapper", which would be the stron= g typedef.
I wouldn't say hiding, just don't looking inside the underlying type. I want to provide access to it (when needed) but only as a whole.
Possibly adding more public methods only using the public interface, which could be done just the same with non-member methods. The end result is a class that cannot be extended in any meaningful way using any of the normal C++ facilities, since every juicy bit is hidden.
Why it is unusable? The class provide access to everything you want.

Classes don't always come with getters and setters for every private field. Especially if the interface they provide is a high level one. It happens often in low-level code that you want to interact with the underlying bits in very specific ways, but you don't necessarily want to give that kind of access to users. So creating a strong typedef of such a class while adding a new mode of operation would be impossible, as the copy won't have access to the underlying implementation.

Another could be when you have to types that you know contain the same (private) data, but should expose different public interfaces. Then you could first create the class containing the data, and copy it two times, each time exposing a different interface (which would need access to the private data). Once again, I unfortunately don't have a practical use case at the moment. I just think it could be useful.

Still the code below is a good use-case I think, since it would be needed to provide strong typedefs of primitive types.
Applying strong-typing again to a strong-typed class would be useless as access to internals would be the same,
You can strong-type again. I don't see the trouble. E.g; you can have a energy strong-type and have kinetic_energy, potential_energy and=C2=A0 heat_energy strong-type of energy.
Typing and representation are two different things. Strong types are just that. Share a representation and have different types.

Yes, of course. What I mean is, you have created a class which can only create exact copies of it. If you need additional changes, it will probably be easier to strong-type the original again and create new trampolines from that. This is what I mean by non-extendable.
 Why? I don't understand.
aside from possibly adding more data (if needed) in the public attributes, since only those are editable. This would also prevent encapsulation of new data. If not, it would just mean that the feature wouldn't be used i= n a composable way.
 I believe now that strong-type shouldn't add any new non-static data member

I start to see what you mean. But still, if one could add them, the copy would still "contain" an equival= ent of the original class at its beginning. It wouldn't be guaranteed reinterpret_cast-able, but the fields would be there anyway. The original representation is there - so to me it could still be considered a strong-typedef (stretching a bit the definition maybe).
 Remember that you need conversions from both sides to implement the trampolines.

Is there any other reason why you don't like the idea?=
No, but it is enough.
A feature that creates a non-extendable object is like a dead-end.
 I must agree with your last sentence, but I don't think the strong-types I'm suggesting are non-extendable?

Well, if only the public interface is available, than adding new methods to it is pretty much equivalent with creating non-member functions (since those work with public interface). Then you might as well remove the ability to add new member functions, since non-members will do just fine and there's no need to have them as members.
 People like member functions also ;-)

But wrappers can be made in a separate library. Why should they be included in the proposal? As long as the proposal allows them, a library only needs to be made once (and if not needed by someone, not used).
 We need some probe of concept applied to concrete examples we want to solve. I believe a strong type feature must solve the builtin type case. If your proposal is not a strong type proposal, then forget my comments.

This is how I would practically solve the primitive types problem using my proposal:

------------------------------------------

// library.hpp

template <typename T>
class Wrap {
=C2=A0=C2=A0=C2=A0 public:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using base_type = =3D T;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Wrap(const Wrap &a= mp; other) : t_(other.t_) {}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 explicit Wrap(T t)= : t_(t) {}
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 private:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T t_;
};

template <typename C>
class ConvertBack : using C {
 public:
=C2=A0=C2=A0=C2=A0 operator base_type() { return t_; }
};

template <typename C>
class Plus : using C {
 public:
=C2=A0=C2=A0=C2=A0 Plus operator+(Plus other) { return Plu= s{t_ + other.t_}; }
};

template <typename C>
class Minus : using C {
=C2=A0=C2=A0=C2=A0 Minus operator-(Minus other) { return Minu= s{t_ - other.t_}; }
};

template <typename C>
class Prod : using C {
=C2=A0=C2=A0=C2=A0 Prod operator+(Prod other) { return Prod{t= _ * other.t_}; }
};

template <typename C>
class Div : using C {
=C2=A0=C2=A0=C2=A0 Div operator/(Div other) { return Div{t_ /= other.t_}; }
};

template <typename T>
using Arithmetic =3D Div<Prod<Minus<Plus<Wrap<T>>>>>;

// .... and so on

// usercode.cpp

#include "library.hpp"

// Strong typedef of int with +,-,/,*
struct MyInt : using Arithmetic<int> {}

// Strong typedef of double with +,- convertible to double struct MyDouble : using ConvertBack<Minus<Plus<Wrap<double>>&g= t;> {}

 This example is already more complete. Thanks.
--------------------------------------------
ConvertBack will convert to Minus<Plus<Wrap<double>>> :(

Maybe the conversion should be part of Wrap or wrap should provide a underlying function as I have in my library.

operator+ returns Plus<Wrap<double>> but we want MyInt or MyDouble :(

See below how you could return the Final class.

If there's something missing you'= ;d like to see how I'd do, let me know. Of course verbosity depends o= n granularity. If all operations need to be manually selected you'll have lots of classes. If the granularity required is less each class could add more operators at once.

Note that you need access to privates to be able to do this, so this could be an use-case for that.
 I like the idea and yes it needs access to the private data. However if we want to be able to provide the conversion to the underlying type, it seems that the underlying data=C2=A0 is no more private anymor= e and should at least be read. To be fair, I have never created strong types for classes that are not builtin types, or that are not copied completely. If the function you want to add modifies only part of the underlying type then either the underlying type provides already this possibility, or the new type would need access to the private part as you propose.

I would need to see how I could adapt my Opaque library with this language feature and see if it could be more simple. I will try with private and without access.

A problem that is not tackled in this code and that we are also discussing is what to do with non-member functions (that could possibly take base_type as input). That depends on how non-member functions will be handled in the proposals. If they can be handled I would actually be happier.
 template <typename Final, typename C>
class AFct : using C {
public:
=C2=A0=C2=A0=C2=A0 friend Final aFct(Final other) { return Final{aFct(o= ther.t_)}; }
};

Forcing the user to inherit to add more data adds inheritance, which means that types are now implicitly convertible (to at least a common base). I don't think this is desirable= .. I think strong typing should work on its own.
 How then you will be able to construct a B from a A if B adds more non-static data members?

One option is to simply define a constructor in B which takes A. Otherwise, it would be the same case when you create a class with a member which the constructor does not initialize. Otherwise one exception could be made for constructors so that they can be redefined in the new class. This probably makes sense and it shoudn't be possible to break something (unless one creates a constructor which does not initialize some fields which are assumed initialized by the original class.. but then I believe it's a reasonable risk).
 I suggest you try it and see how it works. Let me know if it is reasonable.

As you want to = inherit all the member functions from the underlying class, it has a sens to concentrate on member functions. I don't understand why friend functions could not follow the same schema.

Well, friend functions are not members, so if you allow copying them, you are allowing copying arbitrary non-member functions (which I approve of). The only problem with this is that it is a big change - on top of this proposal. Just that.
 Not exactly. The compiler can copy the friend functions because it is aware of these functions and so it could copy them.=

void foo(int);

void foo(double) : using foo(int);

to use an analogous syntax to the one in my proposal. Not sure if this is clearer, let me know.
 I believe I understand you now but I don't see ho= w this could help.
=C2=A0
Well, this would be the way to create the "trampolines" for non-member functions. When you co= py a class, you specify just once from which class you are copying. The compiler can then apply the change to all member functions automatically.

However, you still have to specify non-member functions manually, since the compiler cannot assume you want them all.
 I believe you could let the user copy non-member non-friend function by itself.
and also to A (since C is a type-copy of a type-copy).
 The first Opaque proposal contained a implicit subsumption relation that allowed that. I'm all for, but I believe the committee doesn't like transitivity in conversions.

Well, it is not really transitivity. As in, the C to A transition does not need an implicit transition from B. The user is explicitly creating the conversion operator. The data in C exists, so it can be copied directly. Maybe you mean transitivity in the sense that the compiler needs to remember that C is a copy of B in order for it to know that it is also a copy of A. In that case I agree.
 Yes this is the case. You are requesting the compiler to do the conversion transitively.


Vicente

--
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/std-proposals/edb4= 2928-1e58-ee22-79ce-0fedd07247f1%40wanadoo.fr.

--
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= sJCyDr4sVhXK-9c9cn0JOdaWt7Fr1ejiCBVT7Ab%3DYbew%40mail.gmail.com.
--f403045dd9604a4623054520a069-- .