220 27204 article Path: news.gmane.org!not-for-mail From: Derek Ross Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Generalized "using" member aliases. Date: Fri, 22 Jul 2016 07:58:52 -0700 (PDT) Lines: 175 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_374_777315557.1469199532371" X-Trace: ger.gmane.org 1469199541 11727 80.91.229.3 (22 Jul 2016 14:59:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Jul 2016 14:59:01 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDJJ7WHE3YKRBLPJZC6AKGQEHBPRQGY@isocpp.org Fri Jul 22 16:58:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bQbui-0001vD-Ts for gclcip-std-proposals@m.gmane.org; Fri, 22 Jul 2016 16:58:57 +0200 Original-Received: by mail-pf0-f200.google.com with SMTP id p64sf235659588pfb.0 for ; Fri, 22 Jul 2016 07:58:56 -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=tAv/LKN3OaTt0xNXcQBtgTqwMi3RUWsCdPIc+/ssLPI=; b=Hql8RuKdoa7tAACDMAcgTZ80GmSpSN2h0szQo7hOf/Zf2Oq0111DCgZiknvPaXkB0W V0NqgrGXjt4bayKbpBh+ufKB19PO5g0Er8GJPfYGYLRyoEO82mYcln2tfohQyMS1ofFA b0xLPzSGKTSS81+c86PtA0nDKBiWSREGTCTDtK4/hL87pItUgJtxtRAWKQPeiWBA1Ya/ f9Lx0o4mUEQWdFI7j9De2mb9rGaI0n8MSoBfIbq470AV2tfveYgAPzCgHIyCb/lbgKZM pIeHoQ24tMrNTw4C5k7Us6Y2kxrm6hL3sxWjaP+fzDD5w6Tzt1kxzOSwcctZIHwqy7lX Xl2g== 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=tAv/LKN3OaTt0xNXcQBtgTqwMi3RUWsCdPIc+/ssLPI=; b=Vqnw44Pe8iCS/ILYgX5zmedFIUu9VJOx8o072BbRVukENsSYRW8cqzbpx3OaWBQ5RN 8rv0WcRwN9PAPWKJ5Rw4t7LXhmnVYG92CEcrDywXqpzL8PLDx8L5YqSAhZa3OSyih/V2 LVANNiYunxPmlJSGKpn5gvdHwlEsxz8soSbm9TAZ9jI/OAEjyhGnyFa+Y55rcmzWSeHN RH2kdQTCBNuzG4yZUlfFoHkZLKq05CCRLnhjpME765dluUqJMTdYHVg4iFcEMUKEe2HI UwNY4DhHUv1aTP1Zf5gvsZ0K51mmwR1L1cgT1cz0EDaY9ap7qQWY1qj70ML1BtssXcEL nxCQ== 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=tAv/LKN3OaTt0xNXcQBtgTqwMi3RUWsCdPIc+/ssLPI=; b=Ud5OGHnZZzAiCMWvq54vX2bvdtvA0nk5ImmnKkSKTdhmReHpjI1TKjaRetWLBcpQsK F/14inv07KSPRrMjOnyp3dxqIjMN0bnpIO/XcAza5dtji3ZpUR0LAUoGwUIH7MUuFY7a 2Z5pioIJS0NvdULWMnkUVQLWVwWRljpvHg792dt6rYd6vmVN5gxtxiv7GIMYdAU7s319 0+xfoRmcrD0qWlUjXqrxKn2KqVGKTkiNftEDePZhxObFOhFGEQIK355JUCVMd1Jz0PBt sEbWrH5LL128HJ7aBMx2Kan1Oq4Sfriywol3IT3GhPnX5fCXjQMByY0R3wDQxhqYZ8hL WCrw== X-Gm-Message-State: AEkooutRoLw/oV7ETkK9Wla+UbWmK6D+0Fio9J9KEc75NYgIxsxf7xZbUrg+tj+QHUbJCA== X-Received: by 10.66.255.6 with SMTP id am6mr3751845pad.15.1469199535777; Fri, 22 Jul 2016 07:58:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.19.150 with SMTP id 22ls1591974iot.17.gmail; Fri, 22 Jul 2016 07:58:53 -0700 (PDT) X-Received: by 10.36.222.198 with SMTP id d189mr187102itg.2.1469199533433; Fri, 22 Jul 2016 07:58:53 -0700 (PDT) In-Reply-To: X-Original-Sender: antiquarktv@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:27204 Archived-At: ------=_Part_374_777315557.1469199532371 Content-Type: multipart/alternative; boundary="----=_Part_375_521357246.1469199532372" ------=_Part_375_521357246.1469199532372 Content-Type: text/plain; charset=UTF-8 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 the > outer scope, which might well overlap? > It would be the same as a member variable having the same name as a type in the outer scope. So, already a solved problem. > "ExistingName could also specify a function, e.g., "ExistingName()", in > which case NewName becomes a property-like element." > - 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 "property-like > elements" anyway if the function signature doesn't return a modifiable > reference. > I am confident that C++ developers will be able to wrap their minds around it. > "Member aliases could also be used to shorten inconveniently long names" > - thereby producing 2 names for the same object, 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 namespace American_Telephone_and_Telegraph { ... } using ATT = American_Telephone_and_Telegraph; or shortening typenames like: using vecvecstr = std::vector>; > "This brings 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 > design slightly easier for the lazy > If there were an easy way to convert a struct to a tuple, then some current topics such as reflection or default comparisons (see links), could be implemented as a library rather than by changing the language. 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 ---- Cheers, Derek -- 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/bcee3692-87df-4f63-b8c6-dcba5601a105%40isocpp.org. ------=_Part_375_521357246.1469199532372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B. wrote:=
How woul= d one disambiguate between 'aliased members' and typenames in the o= uter scope, which might well overlap?=C2=A0

It would be the same as a member variable having the same = 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., "Exi= stingName()", in which case NewName becomes a property-like element.&q= uot;
- But then we have horribly ambiguous syntax for whether something = is a member variable or method, requiring us to constantly consult the clas= s to unearth byzantine using declarations, which don't produce "pr= operty-like elements" anyway if the function signature doesn't ret= urn a modifiable reference.

I am confident that C++ developers will be able to wrap their minds around= it.=C2=A0
=C2=A0
"Member aliases could also be used to shorten= inconveniently long names"
- thereby producing 2 names for the sam= e object, cluttering the namespace and introducing ambiguity, merely to rem= ove 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_Telephone_and_Telegraph { ... }=

using= ATT =3D American_Telephone_and_Telegraph;
<= /code>

or shortening typenames like:=C2=A0

using vecvecstr =3D std::vector<std::v= ector<<= /span>std<= span style=3D"color: #660;" class=3D"styled-by-prettify">::string>>;
<= /div>
=C2=A0
"This brings tuples one step closer to being a struct re= placement"
- sounds like ominous portent to me. structs = aren't tuples, and tuples aren't structs. Neither should replace th= e other. Do we really need to introduce a bunch of problems such as the abo= ve just to make interface design slightly easier for the lazy

If there were an easy way to convert a s= truct to a tuple, then some current topics such as reflection or default co= mparisons (see links), could be implemented as a library rather than by cha= nging the language.=C2=A0

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
=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/bcee3692-87df-4f63-b8c6-dcba5601a105= %40isocpp.org.
------=_Part_375_521357246.1469199532372-- ------=_Part_374_777315557.1469199532371-- .