220 27294 <9323492b-fd49-4819-8abe-c1c08252b617@isocpp.org> article Path: news.gmane.org!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Generalized "using" member aliases. Date: Tue, 26 Jul 2016 18:47:32 -0700 (PDT) Lines: 162 Approved: news@gmane.org Message-ID: <9323492b-fd49-4819-8abe-c1c08252b617@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_1747_875311857.1469584052573" X-Trace: ger.gmane.org 1469584062 6068 80.91.229.3 (27 Jul 2016 01:47:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2016 01:47:42 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBBNNF4C6AKGQEQ6YAZWY@isocpp.org Wed Jul 27 03:47:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bSDwd-0003nJ-4l for gclcip-std-proposals@m.gmane.org; Wed, 27 Jul 2016 03:47:35 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id q2sf39093264pap.1 for ; Tue, 26 Jul 2016 18:47:34 -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=AlJ3+tS/CzSTj3+QnwjNF0Djt1M1DRQiahhtu1K/IPk=; b=GJtVi06HiR1ct5m+SSwse4rY88tVkKVQV5dYw8FJJX7NOrJTk54cqLP3xudDKcSd9x mtBC79LDvr6lgYax4wRoJZ0FjC9sWOTkK9+KwDIwP7hH8o04PctIeVugPDM1UIfWikEn 2OxP35h8rn7XRMonyD9TUEC87/ao6vNB5hlWFUFZmnN3Zd7fZzigi0cqjuSPNIa3M8wo 0J2rMSNzQPF6g7ETWvx5R0nA2ldhlFHM37e06OxCLq13l0pIc/0i9a9awY/rS2PtIlHK 1jBXnNba7V0tSfjIcGlQsgqoSSbvr8HngwrEsNzljNoUSkxTu11w6JLTqWCSDUD+yfeg RqQg== 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=AlJ3+tS/CzSTj3+QnwjNF0Djt1M1DRQiahhtu1K/IPk=; b=OkLwD+CI7UMX+LhuOTc+KrKqT1Mrs7SKJZuwtyb17yTHWMOqc9iBWp6ny93wW6R80N Q1Ne8FNMTJsAYxurhMelPJanLZ4LlnuK6w4Cds4jCe/qpT6fjg2PpT97UORlRmv2sFhf +f9dMpcbGs3UnkPUADbUFonmn4z3QXpDoiijxgUdibtH4NQcwCkPJ/TbRDJ6hw1l7Yfy WoovtpqJp2NCH/efwwCNvMWMJjiFEoRtR0/TO8Le4UhGajsQV44DBWJyPTHcr4VoiKTG pB4PfSvL7BCZATmiQxXVLsmSP90UqmOBQ24qhdxzpPAIJPPDvXpNd3MjAHiGrX71VPlj H7JQ== 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=AlJ3+tS/CzSTj3+QnwjNF0Djt1M1DRQiahhtu1K/IPk=; b=Zq4hiFQg1ogvfKHDEfIig6aj9vg54kubKme6evnho4h7nAM4DzhIHCb9hhjmQNJB1m wlDcZSWSYM2t2k2Nq28lLHrWDahOmDwnJzowCXgiCfR9VCkdXGgoNzvc8NYnlIr6yM77 AakXOGmneXKUwXY5/xoCAbv8doE/h+tTQQHDsvL5RUmDVirPnxjKM1/1nw236kITPRwn gaILfT1lcgwCbyCvvQjv8EH/coi/NJCap6dmaK4OESsvTj+xUU6029EARJjTi5NVMOPG T4ufNGi12M+G0caPyxLRRlE/3hJMrd8FtHTcEX/SwJD4hFAhXk0vmlpDAdjFAcVRAXVN 2eJQ== X-Gm-Message-State: AEkoouurtdzvuId6SJ6zevaaY/Mq6siCnkrCzckQ3o7/zstSSpBIHu6tmOYtQCo6Kj5nPg== X-Received: by 10.66.43.82 with SMTP id u18mr23789099pal.30.1469584054055; Tue, 26 Jul 2016 18:47:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.47.72 with SMTP id h66ls303310otb.33.gmail; Tue, 26 Jul 2016 18:47:33 -0700 (PDT) X-Received: by 10.157.43.196 with SMTP id u62mr1451118ota.11.1469584053232; Tue, 26 Jul 2016 18:47:33 -0700 (PDT) In-Reply-To: X-Original-Sender: frankhb1989@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:27294 Archived-At: ------=_Part_1747_875311857.1469584052573 Content-Type: multipart/alternative; boundary="----=_Part_1748_670317957.1469584052573" ------=_Part_1748_670317957.1469584052573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC= +8=E4=B8=8B=E5=8D=883:40:38=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A > > How would one disambiguate between 'aliased members' and typenames in the= =20 > outer scope, which might well overlap? Would the former now have to take= =20 > precedence? What would the syntax be for resolving ambiguous aliases? I= =20 > dunno, it seems like a lot of work for little benefit. > > Or for negative benefit in some cases: > > "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 t= o=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 don't see the need when you have applied some workable naming=20 conventions. =20 > "Member aliases could also be used to shorten inconveniently long names" > - thereby producing 2 names for the same object, cluttering the namespace= =20 > and introducing ambiguity, merely to remove the responsibility of users n= ot=20 > to choose stupidly long names? > > Alias declarations are similar here. =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 > > Both struct and tuple are instances of product type=20 s with possible some additional= =20 metadata. Typically, tuples are purely product types, and struts can have= =20 names in their fields, as so-called record type=20 s. Thus, structs= =20 can be viewed as tuples with (mostly) named members as its elements. The=20 names are additional to the elements of ordinary tuple. It would be quite= =20 natural in a language with first class tuples and named member interface=20 based on them. Also note that record types are sometimes too restrictive=20 than necessary, e.g. specifying layout of these types should not require=20 names of members. =20 > ...I dunno, just playing devil's advocate. I've never felt a need for thi= s=20 > and am not convinced that the cited rationales are good things, quite the= =20 > opposite in most cases. > --=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/9323492b-fd49-4819-8abe-c1c08252b617%40isocpp.or= g. ------=_Part_1748_670317957.1469584052573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98= =9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=883:40:38=EF=BC=8CD. B.=E5=86=99= =E9=81=93=EF=BC=9A
How would one disambiguate between 'aliased members' and = typenames in the outer scope, which might well overlap? Would the former no= w have to take precedence? What would the syntax be for resolving ambiguous= aliases? I dunno, it seems like a lot of work for little benefit.

O= r for negative benefit in some cases:

"ExistingName could also = specify a function, e.g., "ExistingName()", in which case NewName= becomes a property-like element."
- But then we have horribly ambi= guous syntax for whether something is a member variable or method, requirin= g us to constantly consult the class to unearth byzantine using declaration= s, which don't produce "property-like elements" anyway if the= function signature doesn't return a modifiable reference.

I don't see the need when you have applied som= e workable naming conventions.
=C2=A0
"Member aliases could also b= e used to shorten inconveniently long names"
- thereby producing 2 = names for the same object, cluttering the namespace and introducing ambigui= ty, merely to remove the responsibility of users not to choose stupidly lon= g names?

Alias declarations are simila= r here.
=C2=A0
"This brings tuples one step closer to being a stru= ct replacement"
- sounds like ominous portent to me. str= ucts aren't tuples, and tuples aren't structs. Neither should repla= ce the other. Do we really need to introduce a bunch of problems such as th= e above just to make interface design slightly easier for the lazy

--
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/9323492b-fd49-4819-8abe-c1c08252b617= %40isocpp.org.
------=_Part_1748_670317957.1469584052573-- ------=_Part_1747_875311857.1469584052573-- .