220 27206 <361901c2-098a-47ea-ab1f-431b35389baa@isocpp.org> article Path: news.gmane.org!not-for-mail From: szollosi.lorand@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Generalized "using" member aliases. Date: Fri, 22 Jul 2016 08:56:25 -0700 (PDT) Lines: 225 Approved: news@gmane.org Message-ID: <361901c2-098a-47ea-ab1f-431b35389baa@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_904_1256354457.1469202985369" X-Trace: ger.gmane.org 1469202993 4133 80.91.229.3 (22 Jul 2016 15:56:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Jul 2016 15:56:33 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDR7PROGSALRBKUEZG6AKGQEUUGRXSY@isocpp.org Fri Jul 22 17:56:29 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bQcoO-0002T1-7V for gclcip-std-proposals@m.gmane.org; Fri, 22 Jul 2016 17:56:28 +0200 Original-Received: by mail-pa0-f72.google.com with SMTP id q2sf199402556pap.1 for ; Fri, 22 Jul 2016 08:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+kAB2KAWg3Mvj6zYKAJer0Sv7zABDgqNGVXZalR5+Hk=; b=Jz4uR28FEch/t6OGy50hRszkJDOFjsD/iOQ7S3fOMLJp6PKhs+cI71uyq9XuzHzWns Cob8omyN14jha9JwBPinDRMHp977zBryytB8QLWmGMZB6apf6wKPIekb4ITJNQZDX0Ma KmY6YY/E+D7eyLccY9O0LVbZ5/wL5OomyXyb6FmqydHiHYv7iZw38KWw1ucVs2Il9VaE eIMToCGjZ5TBLcBpIhqMkPxy5qdSOZ06eca7vLZyFfXCl3Ydz7dWPjrCmb2+8R7S1coe kYDUGtgY0OkFiIUPYO5Msnt+TXOYoQ2SDtrOBsrFCagDsEb4lKK1J5v7E4gwhX56/X85 u8Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+kAB2KAWg3Mvj6zYKAJer0Sv7zABDgqNGVXZalR5+Hk=; b=ON81NDmhvzNl25TJ3ExmxbHJ8dtyYfGUfGM26f6SrTiFMdUVHnYUY0eaU7S56zlTWJ X+zN9XQbpc4bwyl8MqRATVPmM5UDrH2huWDxNRD5gc7MV8p0f313b4oqGyP5kcqfnPy7 Uhp8dSqyDOWvDpWMhmJR/0R7+LyfqRbBqgmjFQHFn7teg+OHvPtFkOqSu2Y82QVYdqeJ q3zRiNafLvJu5Up6PyBDyxn9iFI+6hXzedx9e8pUQ2gLmoqE+iB2Ieg6rLX+B2+i13TO Ry4jAiXV188grSs4DL5dAHbVdC9j1cpJJTMoLlTHd+l1uLQghtBWcAwPUrf1ZlFgCJf8 JjZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=+kAB2KAWg3Mvj6zYKAJer0Sv7zABDgqNGVXZalR5+Hk=; b=hX4TN6n1QywKXziUlKo9vALywzTzemj4sXjauvgzCqZR+TTpWcEgEPjUR3lSM/dEz6 GcbmfHg9zIp0rabiopB2iBlRPzqOU9O2pzG9i1U+7GyIm3vGS5xEhAyNlKz6YLDFWrv1 yM3H6enoKTXQQeE2+9Ho8cZWSf1+QBnmYBCMzJy74zxFLN8D8CxGupgXcMb0YAdTZ2/g HQbFZbfaj9ESoytJNvZmFrWIJdxX4W/VK4u2yRUKx3NhPxsH9Wd/xxuZfsjMyf/YEziA xI85e5FGQwRi/UXWkBsU9InNAGjTcK8Vs7gj38EHohtR8xzpZnpfSnikn1k/PKvV01Kk g/GQ== X-Gm-Message-State: AEkoous50uad0TIDdz002/PHk3nxFZZ7qU2JEnw5+hsfXlrymXKZZrrOo9yMUogZRffEMQ== X-Received: by 10.66.150.136 with SMTP id ui8mr3858213pab.1.1469202987068; Fri, 22 Jul 2016 08:56:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.130.145 with SMTP id m17ls1730720ioi.32.gmail; Fri, 22 Jul 2016 08:56:26 -0700 (PDT) X-Received: by 10.36.111.147 with SMTP id x141mr211324itb.6.1469202986094; Fri, 22 Jul 2016 08:56:26 -0700 (PDT) In-Reply-To: X-Original-Sender: szollosi.lorand@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:27206 Archived-At: ------=_Part_904_1256354457.1469202985369 Content-Type: multipart/alternative; boundary="----=_Part_905_1995812520.1469202985369" ------=_Part_905_1995812520.1469202985369 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, As for the *pair* example, I'd suggest just using references. Note that you= =20 can have a ref to a member of a *tuple* as well. This might or might not=20 have a memory cost depending on your compiler. As for the *using a =3D b();= *=20 syntax, I'm not sure we want to 'hide' function calls behind members, as we= =20 never used to do that in C++ (that's like hidden costs). That said, I'm not= =20 completely against this, as I had this need before as well... -lorro 2016. j=C3=BAlius 22., p=C3=A9ntek 16:58:52 UTC+2 id=C5=91pontban Derek Ros= s a k=C3=B6vetkez=C5=91t=20 =C3=ADrta: > > On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B. wrote: >> >> How would one disambiguate between 'aliased members' and typenames in th= e=20 >> outer scope, which might well overlap?=20 >> > > It would be the same as a member variable having the same name as a type= =20 > in the outer scope. So, already a solved problem.=20 > =20 > >> "ExistingName could also specify a function, e.g., "ExistingName()", in= =20 >> which case NewName becomes a property-like element." >> - But then we have horribly ambiguous syntax for whether something is a= =20 >> member variable or method, requiring us to constantly consult the class = to=20 >> unearth byzantine using declarations, which don't produce "property-like= =20 >> elements" anyway if the function signature doesn't return a modifiable= =20 >> reference. >> > > I am confident that C++ developers will be able to wrap their minds aroun= d=20 > it.=20 > =20 > >> "Member aliases could also be used to shorten inconveniently long names" >> - thereby producing 2 names for the same object, cluttering the namespac= e=20 >> and introducing ambiguity, merely to remove the responsibility of users = not=20 >> to choose stupidly long names? >> > > This is inspired by the recommended way of shortening a long namespace=20 > name, such as=20 > > namespace American_Telephone_and_Telegraph { ... } > > using ATT =3D American_Telephone_and_Telegraph; > > or shortening typenames like:=20 > > using vecvecstr =3D std::vector>;=20 > =20 > >> "This brings tuples one step closer to being a struct replacement" >> - sounds like ominous portent to me. structs aren't tuples, and tuples= =20 >> aren't structs. Neither should replace the other. Do we really need to= =20 >> introduce a bunch of problems such as the above just to make interface= =20 >> design slightly easier for the lazy >> > > If there were an easy way to convert a struct to a tuple, then some=20 > current topics such as reflection or default comparisons (see links), cou= ld=20 > be implemented as a library rather than by changing the language.=20 > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4475.pdf > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4452.pdf > =20 > ---- > Cheers,=20 > Derek > > > --=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/361901c2-098a-47ea-ab1f-431b35389baa%40isocpp.or= g. ------=_Part_905_1995812520.1469202985369 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As for the pair example, I'd suggest= just using references. Note that you can have a ref to a member of a tu= ple as well. This might or might not have a memory cost depending on yo= ur compiler. As for the using a =3D b(); syntax, I'm not sure we= want to 'hide' function calls behind members, as we never used to = do that in C++ (that's like hidden costs). That said, I'm not compl= etely against this, as I had this need before as well...

-lorro
<= br>2016. j=C3=BAlius 22., p=C3=A9ntek 16:58:52 UTC+2 id=C5=91pontban Derek = Ross a k=C3=B6vetkez=C5=91t =C3=ADrta:
On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B= .. wrote:
How w= ould one disambiguate between 'aliased members' and typenames in th= e outer scope, which might well overlap?=C2=A0
=

It would be the same as a member variable having the sa= me name as a type in the outer scope. So, already a solved problem.=C2=A0
=C2=A0
"ExistingName could also specify a function, e.g., "Exist= ingName()", in which case NewName becomes a property-like element.&quo= t;
- But then we have horribly ambiguous syntax for whether something is= a member variable or method, requiring us to constantly consult the class = to unearth byzantine using declarations, which don't produce "prop= erty-like elements" anyway if the function signature doesn't retur= n a modifiable reference.

I= am confident that C++ developers will be able to wrap their minds around i= t.=C2=A0
=C2=A0
"Member aliases could also be used to shorten inconv= eniently long names"
- thereby producing 2 names for the same objec= t, cluttering the namespace and introducing ambiguity, merely to remove the= responsibility of users not to choose stupidly long names?
=

This is inspired by the recommended way of= shortening a long namespace name, such as=C2=A0

namespace American_Te= lephone_and_Telegraph { ... }

using ATT =3D American_Telephone_and_Telegraph;

or shortening ty= penames like:=C2=A0

<= code>
using vecvecstr =3D std::vector<std::vector<std::string>>;
=C2=A0
"This bring= s tuples one step closer to being a struct replacement"
= - sounds like ominous portent to me. structs aren't tuples, and tuples = aren't structs. Neither should replace the other. Do we really need to = introduce a bunch of problems such as the above just to make interface desi= gn slightly easier for the lazy

=
If there were an easy way to convert a struct to a tuple, then some cu= rrent topics such as reflection or default comparisons (see links), could b= e implemented as a library rather than by changing the language.=C2=A0

=C2=A0
----
Cheers,=C2=A0
Derek


--
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/361901c2-098a-47ea-ab1f-431b35389baa= %40isocpp.org.
------=_Part_905_1995812520.1469202985369-- ------=_Part_904_1256354457.1469202985369-- .