220 29982 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A strong typedef syntax idea Date: Wed, 21 Dec 2016 20:20:22 +0100 Lines: 330 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=047d7b5d86955ef86a0544300bb0 X-Trace: blaine.gmane.org 1482348028 13571 195.159.176.226 (21 Dec 2016 19:20:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Dec 2016 19:20:28 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBB6FL5PBAKGQEM3RPEGY@isocpp.org Wed Dec 21 20:20:22 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJmR2-0002fT-OU for gclcip-std-proposals@m.gmane.org; Wed, 21 Dec 2016 20:20:20 +0100 Original-Received: by mail-lf0-f71.google.com with SMTP id d16sf9383714lfb.7 for ; Wed, 21 Dec 2016 11:20:25 -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=Am/BNLAwKwM+Tl1P7/DAUYn4RT/eOkEtxP5Ef/VAPqs=; b=gRgRqTeiRiF4U91kWyzwmOVbpxZ7+tkfZSwHu76zSjcpm1kEWRhAbCV/PztVHlbEmS 3MPS+FuDzkmvcKVp7EbheLvat9pRkfgW1bv8q11wXu0R/j+1a860pDC6hYBSYZNcAOKJ RZh3DDV94LWqEdKhknY7UHeQEOJd9FOFBqJBM53SwFTGPxNUy/XuSs1F14pxbQHbI+Zr +5+cRHJkBGbvkrrvyNJ/Vkf1fQmxohwcUqyuv//dPdFENYf1LADlH5NkW0xEbgp0r44D BEkk1+FgNvFqaelvX4hUzE2PhYwmw1ez87PAOGMQjnH/QJpGxQ60nfweACPYPuCu6UiK UETA== 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=Am/BNLAwKwM+Tl1P7/DAUYn4RT/eOkEtxP5Ef/VAPqs=; b=BHmNsJNFHbX3J/JGTH/oXZ7AyfTa4FRsKfi12lcpqEOlUU2MSYaEkNvmbHnRj6brAW gODQTy3i2fwZzfUaE6+telmhc/Uo2Mjuo57EZ+XUrp/eGdT+WgSUhn1fDDIjdZFYRc68 FHMKVqX5vImM7/7O+EyYN1VZJVKK6WHKa+fES32WQN5fX9ktllx3FpnC4H2EEFwuKGR2 VZbXY7Qgta8z9mS+Sr50SE0XeiJGEym8N9+nCUB7wW91NcPaLN1vvP5j51bYLQn1RS7C VnP1smIusWW5kYKG3GUD0g1f1o6+YWz6Y1nTmwBBofH0ywJlIsroAwMuhPXGY6/SrW4J /Z5g== X-Gm-Message-State: AIkVDXLaH0QiuZ7h9VdwAoAASCIRjGuFaw8rneinwWWSt15V8J5kCuiJLVYvB9xj9f+AXw== X-Received: by 10.25.203.197 with SMTP id b188mr470395lfg.27.1482348025452; Wed, 21 Dec 2016 11:20:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.184.151 with SMTP id i145ls2195822wmf.9.gmail; Wed, 21 Dec 2016 11:20:24 -0800 (PST) X-Received: by 10.194.222.202 with SMTP id qo10mr5841796wjc.115.1482348023967; Wed, 21 Dec 2016 11:20:23 -0800 (PST) Original-Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com. [2a00:1450:400c:c01::22c]) by mx.google.com with ESMTPS id rw15si372941wjb.172.2016.12.21.11.20.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 11:20:23 -0800 (PST) Received-SPF: pass (google.com: domain of mjklaim@gmail.com designates 2a00:1450:400c:c01::22c as permitted sender) client-ip=2a00:1450:400c:c01::22c; Original-Received: by mail-wj0-x22c.google.com with SMTP id sd9so25078269wjb.1 for ; Wed, 21 Dec 2016 11:20:23 -0800 (PST) X-Received: by 10.194.22.41 with SMTP id a9mr6591755wjf.30.1482348023439; Wed, 21 Dec 2016 11:20:23 -0800 (PST) Original-Received: by 10.80.158.1 with HTTP; Wed, 21 Dec 2016 11:20:22 -0800 (PST) In-Reply-To: X-Original-Sender: mjklaim@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of mjklaim@gmail.com designates 2a00:1450:400c:c01::22c as permitted sender) smtp.mailfrom=mjklaim@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:29982 Archived-At: --047d7b5d86955ef86a0544300bb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 operato= r > 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, ther= e > 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 ther= e > 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. Mayb= e > 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 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 barrier of interest, even if Stroustrup is "only" one vote. > For member access, keep in mind that you are making a new class. The risk > 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 o= f > 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 nicer >>> 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 operations >> 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 Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, 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/CAHfn%3D%2Bvo2KXEWQHWQY6qB10oGabvZ9jGai > 3CtWNseLdA7QMNkw%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/CAOU91ONWWCLw_vCxNryKEdgA4W%2BdLr979ZkPDLh7junqx= _DETQ%40mail.gmail.com. --047d7b5d86955ef86a0544300bb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

Not n= ecessarily:

class A
{
=C2=A0 = =C2=A0std::mutex my_mutex; // not copyable or moveable, not part of the int= erface
public:

=C2=A0 =C2=A0 A();=C2=A0<= /div>
};

class B : using/cloning A
{= };

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

I agree but in the = same time, most types you need to clone have free functions as part of thei= r interfaces.
This is a classic problem with strong typedefs.
=C2=A0
In any case, I believe this case is what templates are for. They ar= e there to create functions that interact with object with the same interfa= ce, so in this case one would want foo to be a templated function.

It would be nice but you are talking ab= out a function you might not have control over with.
It can be so= lved with a cast though.
=C2=A0
Copy + Template would be the equivalent of Inheri= tance + 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 th= e 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 t= hat 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 pu= t the feature back in discussion will have to pass a higher barrier of inte= rest, even if Stroustrup is "only"
one vote.
= =C2=A0
For = member access, keep in mind that you are making a new class. The risk is ex= actly 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 pri= vate members, only B's, which is different since it is another class en= tirely. Why then you would want to create a new class which ignores access = specifiers is another problem, but one that exists independently of this pr= oposal.

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@gmail.com> wrote:<= br>
Jo=C3=ABl, about copy I feel the same way. I'll try to work out a nic= er terminology.

Maybe use "c= lone-type" or something like that?
Anyway yeah even for functions overloadin= g there is always the same problem with any kind of strong typedef:

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

void foo(A& a);<= /div>

Here y= our 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 oper= ations from A to B?

Also isn'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<= /div>
{
public:

=C2=A0 = =C2=A0int cheat() { return hidden_value; }
= };

This looks necessary but a bit problemati= c also. Apparently Modules wouldn't change a thing as long
as type members are all considered exported.

Jo=C3=ABl Lamott= e


=


<= /div>

--
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%2Bvo2KXEWQHWQY6qB10oGabvZ9jGai3CtWNse= LdA7QMNkw%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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONWWCLw_v= CxNryKEdgA4W%2BdLr979ZkPDLh7junqx_DETQ%40mail.gmail.com.
--047d7b5d86955ef86a0544300bb0-- .