220 29984 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 20:28:11 +0100 Lines: 445 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=001a114fa2344923ae05443027df X-Trace: blaine.gmane.org 1482348495 28694 195.159.176.226 (21 Dec 2016 19:28:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Dec 2016 19:28:15 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCWJHLVBTMARBTFP5PBAKGQER6QUJZY@isocpp.org Wed Dec 21 20:28:08 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJmYa-0006j9-Jm for gclcip-std-proposals@m.gmane.org; Wed, 21 Dec 2016 20:28:08 +0100 Original-Received: by mail-it0-f69.google.com with SMTP id o141sf144533586itc.1 for ; Wed, 21 Dec 2016 11:28:13 -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=Y2DxLgryP8sKcXikCpcRwicl+9k81Gwb7VxZxX+y8gk=; b=YJ04LyqZSOJCTd1oJMbrGU1jZphAtyJ1uap8EaO32Hmd40omt7kmMOSdNKd3lC2zmE ekJ1y9e9755G9hjOKKlzIOs9Xmi7k8gx9tU1+XZtOmMKcLnpZpRQBLxWfuJaAQ/gReOY Svr+I/ia9mnQQookX4hTBhy5wLIc/2nbSkbm0++ynYyGNuYW4NdBM/s4sW0clVEh36kS 1VX7kzHjTCERUt0B9vjKGJ2RlQFf+4n6RDzm99DBBeNAiOciSQ9khZYlhQREUH/7TVEd 5x+gUJlxn7RzJOhOQx93tZtP312YADh4rbna3YMFW8lhsRHU+1PlyRhzYRXQ6m+ZeIQ9 mZMg== 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=Y2DxLgryP8sKcXikCpcRwicl+9k81Gwb7VxZxX+y8gk=; b=d2co4LErm04/9Hy0V9uPfoyUpDQn7hzm+ImYbHMp5X9yS+MToa1t+E571PXxAEzwpI qBex5BukH/S1S+eIPGc0V/OzX8FpKLE8gIRGxOgtZ6xIyM2XzFkv4vQlP5B6fVo7aQj0 CPIxKrckVTRTVo+Yv86kdcZGfi5Fczgu5e+tOU/LtVFWMZJqhD3zpeVHhzwnvDYXnaSU d5hxoElHnuqvin2DPH7RKrARDZUfu1rjTX1mU9eL+gJck36GYUNHzGbwiXMYRGoJdkfR w5Ky+X7tdKdXWVMLQSn0k3iv8HLYhGi+39k42ryCq+wHOL1IrXeC907zZY/Zgvv9K00j S4IA== X-Gm-Message-State: AIkVDXL71Ub/di2+meiTk/PIsaHDTd+lw3Kiob7GSOoSqyen9D3MIk7YQle9+rtlyIiqjw== X-Received: by 10.36.80.72 with SMTP id m69mr1245704itb.39.1482348492909; Wed, 21 Dec 2016 11:28:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.55.165 with SMTP id x34ls18242588otb.8.gmail; Wed, 21 Dec 2016 11:28:12 -0800 (PST) X-Received: by 10.159.35.21 with SMTP id 21mr4734454uae.173.1482348492236; Wed, 21 Dec 2016 11:28:12 -0800 (PST) Original-Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com. [2607:f8b0:400c:c08::230]) by mx.google.com with ESMTPS id g10si2284747uaf.250.2016.12.21.11.28.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 11:28:12 -0800 (PST) Received-SPF: pass (google.com: domain of svalorzen@gmail.com designates 2607:f8b0:400c:c08::230 as permitted sender) client-ip=2607:f8b0:400c:c08::230; Original-Received: by mail-ua0-x230.google.com with SMTP id 34so25670541uac.1 for ; Wed, 21 Dec 2016 11:28:12 -0800 (PST) X-Received: by 10.159.41.2 with SMTP id t2mr3855838uat.5.1482348491775; Wed, 21 Dec 2016 11:28:11 -0800 (PST) Original-Received: by 10.31.227.133 with HTTP; Wed, 21 Dec 2016 11:28:11 -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::230 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:29984 Archived-At: --001a114fa2344923ae05443027df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I agree but in the same time, most types you need to clone have free > functions as part of their interfaces. > This is a classic problem with strong typedefs. > I agree, I have though a while about this while writing this proposal. I thought about giving the possibility of "cloning" a function (as in, creating an equivalent version line by line with just all instances of the copied type replaced by the new type) within the scope of the copied class. But then I realized that if that was allowed, at that point it might as well be allowed for all classes, for all functions. And so it would become a feature on its own, or at least a very big scope increase. Thus I removed it from the proposal. If you feel that such a feature cannot be reasonably excluded from a complete proposal about strong typing, I'll try to think about a way to extend the syntax for functions, or even better find something which looks equally good for both classes and functions. My first guess was that maybe trying to keep the proposal as limited in scope as possible would be best, so that it would be easier what could go wrong. Even a small step towards strong typing would be better than nothing, I guess. Even if some classes can be harder to copy/clone if they are mostly defined by their free-functions ecosystem, still there's many for which this is not true. But again, if you feel it would be best to think about this and try to add it, I'll definitely try to. On Wed, Dec 21, 2016 at 8:20 PM, Klaim - Jo=C3=ABl Lamotte wrote: > > > On 21 December 2016 at 19:41, Eugenio Bargiacchi > wrote: > >> I suppose that if we want to use foo with B, one could include an >> operator A() to B. >> > > Not necessarily: > > class A > { > std::mutex my_mutex; // not copyable or moveable, not part of the > interface > public: > > A(); > }; > > class B : using/cloning A > {}; > > I expect this to work but not that B could be convertible to A without a > static cast. > > >> In any case, the point in making a strong typedef is that you are indeed >> making a new type. If it was completely compatible with the old one, the= re >> would be little point, right? >> >> > I agree but in the same time, most types you need to clone have free > functions as part of their interfaces. > This is a classic problem with strong typedefs. > > >> In any case, I believe this case is what templates are for. They are >> there to create functions that interact with object with the same >> interface, so in this case one would want foo to be a templated function= .. >> > > It would be nice but you are talking about a function you might not have > control over with. > It can be solved with a cast though. > > >> Copy + Template would be the equivalent of Inheritance + Interfaces. >> Maybe a way to clone functions could be added in order to interface with >> old code, but I'm not sure whether it should be in the scope of this >> proposal or be separated in another one. >> >> > Maybe not, maybe begin with what you have to get initial feedback. > I watched recently Stroustrup explain that in the end he is not for stron= g > typedefs feaures anymore, because just create a type and go with it. > So I believe that any attempt to put the feature back in discussion will > have to pass a higher barrier of interest, even if Stroustrup is "only" > one vote. > > >> For member access, keep in mind that you are making a new class. The ris= k >> is exactly the same when you create a new class and expose members which >> should be private. In any case, this won't make you able to access A's >> private members, only B's, which is different since it is another class >> entirely. Why then you would want to create a new class which ignores >> access specifiers is another problem, but one that exists independently = of >> this proposal. >> >> > Ah yes, I understand. > > > >> On Wed, Dec 21, 2016 at 7:12 PM, Klaim - Jo=C3=ABl Lamotte >> wrote: >> >>> >>> On 21 December 2016 at 13:41, Eugenio Bargiacchi >>> wrote: >>> >>>> Jo=C3=ABl, about copy I feel the same way. I'll try to work out a nice= r >>>> terminology. >>>> >>> >>> Maybe use "clone-type" or something like that? >>> >>> Anyway yeah even for functions overloading there is always the same >>> problem with any kind of strong typedef: >>> >>> class A {}; >>> class B : using/cloning A {}; >>> >>> void foo(A& a); >>> >>> Here your proposal suggests that foo() cannot be used with B. >>> But maybe we want that to be possible? >>> Add a way to clone free functions too? How about allowing all operation= s >>> from A to B? >>> >>> Also isn't there a risk of member access? >>> >>> class A { >>> int hidden_value; >>> public: >>> A(); >>> }; >>> >>> class B : using/cloning A >>> { >>> public: >>> >>> int cheat() { return hidden_value; } >>> }; >>> >>> >>> This looks necessary but a bit problematic also. Apparently Modules >>> wouldn't change a thing as long >>> as type members are all considered exported. >>> >>> Jo=C3=ABl Lamotte >>> >>> >>> >>> >>> -- >>> 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/CAOU91OOQe0Cq1QS1bR1X0EsWDWZe >>> bChkjoT3Dw7%2Bp9H6AAg_tw%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%2Bvo2KXEWQHWQY6qB10o >> GabvZ9jGai3CtWNseLdA7QMNkw%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/ > 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/CAOU91ONWWCLw_vCxNryKEdgA4W% > 2BdLr979ZkPDLh7junqx_DETQ%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%2BvYTB4zJT7zsQ8chPRJCj7m%3DP3yv1v_tMREZ= jfr%3DeSFpA%40mail.gmail.com. --001a114fa2344923ae05443027df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree but in the same time, most types you need to clone= have free functions as part of their interfaces.
This is a class= ic problem with strong typedefs.

I agree, I have thou= gh a while about this while writing this=20 proposal. I thought about giving the possibility of "cloning" a f= unction (as in, creating an equivalent version line by line with just all=20 instances of the copied type replaced by the new type) within the scope=20 of the copied class.

But then I realized that if that was=20 allowed, at that point it might as well be allowed for all classes, for all= functions. And=20 so it would become a feature on its own, or at least a very big scope incre= ase. Thus I removed it from the=20 proposal.

If you feel that such a feature cannot be reasonably= excluded from a complete proposal about strong typing, I'll try to thi= nk about a way to extend the syntax for functions, or even better find some= thing which looks equally good for both classes and functions.

My first guess was that maybe trying to keep the proposal as limited in sc= ope as possible would be best, so that it would be easier what could go wro= ng. Even a small step towards strong typing would be better than nothing, I= guess. Even if some classes can be harder to copy/clone if they are mostly= defined by their free-functions ecosystem, still there's many for whic= h this is not true.

But again, if you feel it would be best to= think about this and try to add it, I'll definitely try to.
<= div class=3D"gmail_extra">
On Wed, Dec 21, 20= 16 at 8:20 PM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com>= wrote:


On 21 Dece= mber 2016 at 19:41, Eugenio Bargiacchi <svalorzen@gmail.com> wrote:
I su= ppose that if we want to use foo with B, one could include an operator A() = to B.

Not necessar= ily:

class A
{
=C2=A0 =C2=A0st= d::mutex my_mutex; // not copyable or moveable, not part of the interface
public:

=C2=A0 =C2=A0 A(= );=C2=A0
};

class B : using/cloning A
{};

I expect this to work but not t= hat B could be convertible to A without a static cast.
=C2=A0
In any case, the point in making a strong typedef is that you are indeed= making a new type. If it was completely compatible with the old one, there= would be little point, right?

<= br>
I agree but in the same time, most types you need to c= lone have free functions as part of their interfaces.
This is a c= lassic problem with strong typedefs.
=C2=A0
In any cas= e, I believe this case is what templates are for. They are there to create = functions that interact with object with the same interface, so in this cas= e one would want foo to be a templated function.

It would be nice but you are talking about a funct= ion you might not have control over with.
It can be solved with a= cast though.
=C2=A0
Copy + Template would be the equivalent of = Inheritance + Interfaces. Maybe a way to clone functions could be added in = order to interface with old code, but I'm not sure whether it should be= in the scope of this proposal or be separated in another one.


Maybe not, maybe begin with = what you have to get initial feedback.
I watched recently Stroust= rup explain that in the end he is not for strong typedefs feaures anymore, = because just create a type and go with it.
So I believe that any = attempt to put the feature back in discussion will have to pass a higher ba= rrier of interest, even if Stroustrup is "only"
one vot= e.
=C2=A0
For member access, keep in mind that you are maki= ng a new class. The risk is exactly the same when you create a new class an= d expose members which should be private. In any case, this won't make = you able to access A's private members, only B's, which is differen= t since it is another class entirely. Why then you would want to create a n= ew class which ignores access specifiers is another problem, but one that e= xists independently of this proposal.
<= br>

Ah yes, I understand.

=C2=A0
On Wed, Dec 21, 2016 at 7:12 PM, Klaim = - Jo=C3=ABl Lamotte <mjklaim@gmail.com> wrote:

On 21 December 2016 at 13:41, Eugenio Bargiacchi <svalorzen@gma= il.com> wrote:
Jo=C3=ABl, about copy = I feel the same way. I'll try to work out a nicer terminology.

Maybe use "clone-type" or somet= hing like that?

Anyway yeah even for functions overloading there is always the sa= me problem with any kind of strong typedef:

class A {};
class B : using/cloning A {};

void foo(A& a);

Here your proposal suggests th= at foo() cannot be used with B.
But maybe w= e want that to be possible?
Add a way to cl= one free functions too? How about allowing all operations from A to B?

Also isn&#= 39;t there a risk of member access?

class A {=C2=A0
=C2=A0 =C2=A0 int hidden_value;=C2=A0
= =C2=A0 public:
=C2=A0 =C2=A0 =C2=A0 A();
};

=
class B : using/cloning A
{
public:

=C2=A0 =C2=A0int cheat() { re= turn hidden_value; }
};


This looks necessary but a bit problematic also. Apparently Mod= ules wouldn't change a thing as long
as= type members are all considered exported.
=
Jo=C3=ABl Lamotte




--
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/CAOU91OOQe0Cq1QS1bR1X0EsWDWZebChkjoT3Dw7%2Bp9H6AAg_tw= %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/msgid/= std-proposals/CAHfn%3D%2Bvo2KXEWQHWQY6qB10oGabvZ9jGai3CtWNseLdA7Q= MNkw%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/CAOU91ONWWCLw_vCxNryKEdgA4W%2BdLr979ZkPDLh7junqx= _DETQ%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%= 2BvYTB4zJT7zsQ8chPRJCj7m%3DP3yv1v_tMREZjfr%3DeSFpA%40mail.gmail.com. --001a114fa2344923ae05443027df-- .